[要約] RFC 3075は、XMLデータの署名構文と処理方法を定義しています。このRFCの目的は、XMLデータの信頼性とセキュリティを向上させることです。
Network Working Group D. Eastlake
Request for Comments: 3075 Motorola
Category: Standards Track J. Reagle
W3C/MIT
D. Solo
Citigroup
March 2001
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) 2001 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
Copyright（c）2001 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. Editorial Conventions .................................. 3
2. Design Philosophy ...................................... 4
3. Versions, Namespaces and Identifiers ................... 4
4. Acknowledgements ....................................... 5
2. Signature Overview and Examples ............................. 6
1. Simple Example (Signature, SignedInfo, Methods, and
References) ............................................ 7
1. More on Reference ................................. 9
2. Extended Example (Object and SignatureProperty) ........ 10
3. Extended Example (Object and Manifest) ................. 11
3. Processing Rules ............................................ 13
1. Core Generation .... ................................... 13
1. Reference Generation .............................. 13
2. Signature Generation .............................. 13
2. Core Validation ........................................ 13
1. Reference Validation .............................. 14
2. Signature Validation .............................. 14
4. Core Signature Syntax ....................................... 14
1. The Signature element .................................. 15
2. The SignatureValue Element ............................. 16
3. The SignedInfo Element ................................. 16
1. The CanonicalizationMethod Element ................ 17
2. The SignatureMethod Element ....................... 18
3. The Reference Element ............................. 19
1. The URI Attribute ............................ 19
2. The Reference Processing Model ............... 21
3. Same-Document URI-References ................. 23
4. The Transforms Element ....................... 24
5. The DigestMethod Element ..................... 25
6. The DigestValue Element ...................... 26
4. The KeyInfo Element .................................... 26
1. The KeyName Element ............................... 27
2. The KeyValue Element .............................. 28
3. The RetrievalMethod Element ....................... 28
4. The X509Data Element .............................. 29
5. The PGPData Element ............................... 31
6. The SPKIData Element .............................. 32
7. The MgmtData Element .............................. 32
5. The Object Element ..................................... 33
5. Additional Signature Syntax ................................. 34
1. The Manifest Element ................................... 34
2. The SignatureProperties Element ........................ 35
3. Processing Instructions ................................ 36
4. Comments in dsig Elements .............................. 36
6. Algorithms .................................................. 36
1. Algorithm Identifiers and Implementation Requirements .. 36
2. Message Digests ........................................ 38
1. SHA-1 ............................................. 38
3. Message Authentication Codes ........................... 38
1. HMAC .............................................. 38
4. Signature Algorithms ................................... 39
1. DSA ............................................... 39
2. PKCS1 ............................................. 40
5. Canonicalization Algorithms ............................ 42
1. Minimal Canonicalization .......................... 43
2. Canonical XML ..................................... 43
6. Transform Algorithms ................................... 44
1. Canonicalization .................................. 44
2. Base64 ............................................ 44
3. XPath Filtering ................................... 45
4. Enveloped Signature Transform ..................... 48
5. XSLT Transform .................................... 48
7. XML Canonicalization and Syntax Constraint Considerations ... 49
1. XML 1.0, Syntax Constraints, and Canonicalization ..... 50
2. DOM/SAX Processing and Canonicalization ................ 51
8. Security Considerations ..................................... 52
1. Transforms ............................................. 52
1. Only What is Signed is Secure ..................... 52
2. Only What is "Seen" Should be Signed .............. 53
3. "See" What is Signed .............................. 53
2. Check the Security Model ............................... 54
3. Algorithms, Key Lengths, Etc. .......................... 54
9. Schema, DTD, Data Model,and Valid Examples .................. 55
10. Definitions ................................................. 56
11. References .................................................. 58
12. Authors' Addresses .......................................... 63
13. Full Copyright Statement .................................... 64
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 uses both XML Schemas [XML-schema] and DTDs [XML]. (Readers unfamiliar with DTD syntax may wish to refer to Ron Bourret's "Declaring Elements and Attributes in an XML DTD" [Bourret].) The schema definition is presently normative.
この仕様では、XMLスキーマ[XML-Schema]とDTDS [XML]の両方を使用しています。（DTDの構文に不慣れな読者は、Ron Bourretの「XML DTDでの宣言する要素と属性」[Bourret]を参照することを望むかもしれません。）スキーマ定義は現在規範的です。
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」、「shill」、「suff」、「ofs "、" becommented "、" bay "、および「オプション」」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 keywords 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 XML-namespace specification [XML-ns] is described as "REQUIRED."
その結果、これらの大文字のキーワードを使用して、プロトコルとアプリケーションの機能と、実装の相互運用性とセキュリティに影響を与える動作に関する要件を明確に指定します。これらのキーワードは、XML文法を説明するために使用されません（大文字です）。スキーマの定義は、そのような要件を明確に説明しており、プロトコルと機能の自然言語の説明のためにこれらの用語の顕著な留保を留保したいと考えています。たとえば、XML属性は「オプション」であると説明される場合があります。XML-NamesPace Specification [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: 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-NS] URIは、この（日付）仕様の実装で使用する必要があります。/09/XMLDSIG＃ "この名前空間は、この仕様で使用されるアルゴリズム識別子のプレフィックスとしても使用されます。アプリケーションはXMLおよびXML-NamesSpacesをサポートする必要がありますが、内部エンティティ[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/PR-xslt-19991008
XSLTは、外部URI http://www.w3.org/tr/1999/pr-xslt-19991008によって識別および定義されています
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, JetForm Corporation (Author)
* John Boyer, PureEdge (Author)
* Mariano P. Consens, University of Waterloo
*マーク・バーテル、Jetform Corporation（著者）
*ジョン・ボイヤー、ピュアエッジ（著者）
*マリアノP.コンセン、ウォータールー大学
* 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
* Peter Lipp, IAIK TU Graz
* Joseph Reagle, W3C (Chair, Author/Editor)
* Ed Simon, Entrust Technologies Inc. (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.
*ジョン・コーワン、ロイター・ヘルス
*ドナルドイーストレイク3位、モトローラ（椅子、著者/編集者）
*バーブフォックス、マイクロソフト（著者）
* Christian Geuer-Pollmann、大学シーゲン
*トム・ギンディン、イブ
* Phillip Hallam-Baker、Verisign Inc
*リチャード・ヒメス、米国裁判所
*マーリン・ヒューズ、ボルチモア
* Gregor Karlinger、Iaik Tu Graz
*ブライアン・ラマッチア、マイクロソフト
*ピーターリップ、Iaik Tu Graz
*ジョセフ・レーグル、W3C（椅子、著者/編集者）
*エド・サイモン、委任Technologies Inc.（著者）
*デビッド・ソロ、シティグループ（著者/編集者）
* Petteri Stenius、Done Information、Ltd
*ラガヴァン・スリニバス、太陽
* Kent Tamura、IBM
*ウィンチェル・トッド・ビンセント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.
*ダン・コノリー、W3C
* XMLスキーマWGを代表して、カイザーパーマネンテ、ポールビロン。
* Martin J. Duerst、W3C;藤井正田島。国際化WG/IGを代表して。
*ジョナサン・マーシュ、マイクロソフト、拡張可能なStyleSheet Language WGを代表して。
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> <SignedInfo> (CanonicalizationMethod) (SignatureMethod) (<Reference (URI=)? > (Transforms)? (DigestMethod) (DigestValue) </Reference>)+ </SignedInfo> (SignatureValue) (KeyInfo)? (Object)* </Signature>
<Signature> <SignedInfo>（CanonicalizationMethod）（signaturemethod）（<reference（uri =）？（transforms）？（digestmethod）（digestvalue）</reference>）</signedinfo>（signaturevalue）（keyinfo）？（オブジェクト）* </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 resides within the same XML document as sibling elements; in this case, the signature is neither enveloping (signature is parent) nor enveloped (signature is child). Since a Signature element (and its Id attribute 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）と組み合わせることができるため、違反する後続の衝突がないように名前を選択することに注意する必要があります。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/2000/CR-xml-c14n-20001026"/>
[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/2000/
CR-xml-c14n-20001026"/>
[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.
[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 and the signature design permits arbitrary user algorithm specification.
[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 also may 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/2000/
CR-xml-c14n-20001026"/>
[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 than 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 and XPath. 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 we specify mandatory (and optional) canonicalization and decoding algorithms, user specified transforms are permitted.
[S06-08] Transformsは、消化される前にリソースのコンテンツに適用された処理手順のオプションの順序付けられたリストです。変換には、標準化、エンコード/デコード（圧縮/インフレを含む）、XSLT、XPathなどの操作が含まれます。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 (message authentication, integrity, 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/rfc3075.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 follows.
マニフェスト要素は、この仕様の必須部分で直接対処されない追加の要件を満たすために提供されます。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>
3.0 Processing Rules
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.
1. アプリケーションによって決定された変換をデータオブジェクトに適用します。2.結果のデータオブジェクトでダイジェスト値を計算します。
3. Create a Reference element, including the (optional) identification of the data object, any (optional) transform elements, the digest algorithm and the DigestValue.
3. データオブジェクトの（オプションの）識別、任意の（オプションの）変換要素、ダイジェストアルゴリズム、ダイジェストバリューを含む参照要素を作成します。
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. 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.
1. SignatureMethod、CanonicalizationMethod、および参照を使用してSignedInfo要素を作成します。2. signedinfoで指定されたアルゴリズムに基づいて、signedInfo上の署名バリューを正規化して計算します。3. signedInfo、オブジェクト（必要に応じて、エンコードは署名に使用されるものとは異なる場合がある）、keyInfo（必要に応じて）、およびsignaturevalueを含む署名要素を構築します。
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スキームは望ましくない副作用を引き起こす可能性があります）など。
For each Reference in SignedInfo:
SignedInfoの各参照について：
1. Canonicalize the SignedInfo element based on the CanonicalizationMethod in SignedInfo. 2. Obtain the data object to be digested. (The signature application may rely upon the identification (URI) and Transforms provided by the signer in the Reference element, or it may obtain the content through other means such as a local cache.) 3. Digest the resulting data object using the DigestMethod specified in its Reference specification. 4. Compare the generated digest value against DigestValue in the SignedInfo Reference; if there is any mismatch, validation fails.
1. SignedInfoのCanonicalizationMethodに基づいて、SignedInfo要素を正規化します。2.消化するデータオブジェクトを取得します。（署名アプリケーションは、識別（URI）に依存し、参照要素で署名者が提供する変換に依存する場合があります。または、ローカルキャッシュなどの他の手段を介してコンテンツを取得する場合があります。参照仕様で。4. SignedInfoリファレンスのDigestValueに対して生成されたダイジェスト値を比較します。不一致がある場合、検証は失敗します。
Note, SignedInfo is canonicalized in step 1 to ensure the application Sees What is Signed, which is the canonical form. For instance, if the CanonicalizationMethod rewrote the URIs (e.g., absolutizing relative URIs) the signature processing must be cognizant of this.
注意、SignedInfoはステップ1で標準化されており、アプリケーションが署名されているもの、つまり標準的な形式を確認することを確認してください。たとえば、CanonicalizationMethodがURIを書き換えた場合（例えば、相対的なURIを絶対にする）、署名処理はこれを認識しなければなりません。
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 validate 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, internal entity, and simpleType: Schema Definition:
XML署名の一般的な構造については、署名の概要（セクション2）で説明されています。このセクションでは、コア署名機能の詳細な構文を提供します。このセクションで説明する機能は、特に示されない限り実装することが必須です。構文は、次のXMLプリアンブル、宣言、内部エンティティ、およびsimpleTypeを使用して、DTDと[XML-Schema]を介して定義されます。スキーマ定義：
<!DOCTYPE schema
PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN"
"http://www.w3.org/2000/10/XMLSchema.dtd"
[
<!ATTLIST schema
xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
<!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'>
]>
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
xmlns:ds="&dsig;"
targetNamespace="&dsig;"
version="0.1"
elementFormDefault="qualified">
<!-- Basic Types Defined for Signatures -->
<simpleType name="CryptoBinary"> <restriction base="binary"> <encoding value="base64"/> </restriction> </simpleType> DTD:
<simpletype name = "cryptobinary"> <制限base = "binary"> <encoding value = "base64"/> </restriction> </simpletype> dtd：
<!-- These entity declarations permit the flexible parts of Signature
content model to be easily expanded -->
<!ENTITY % Object.ANY '(#PCDATA|Signature|SignatureProperties|
Manifest)*'>
<!ENTITY % Method.ANY '(#PCDATA|HMACOutputLength)*'>
<!ENTITY % Transform.ANY '(#PCDATA|XPath|XSLT)'>
<!ENTITY % SignatureProperty.ANY '(#PCDATA)*'>
<!ENTITY % Key.ANY '(#PCDATA|KeyName|KeyValue|RetrievalMethod|
X509Data|PGPData|MgmtData|DSAKeyValue|RSAKeyValue)*'>
The Signature element is the root element of an XML Signature. Signature elements MUST be laxly schema valid [XML-schema] with respect to the following schema definition: Schema Definition:
署名要素は、XML署名のルート要素です。署名要素は、次のスキーマ定義に関して、[XML-Schema]有効なLaxlyスキーマでなければなりません。スキーマ定義：
<element name="Signature">
<complexType>
<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> </element> DTD:
<要素ref = "ds：signaturevalue"/> <要素ref = "ds：keyinfo" minoccurs = "0"/> <要素ref = "ds：object" minoccurs = "0" maxoccurs = "unbounded"/> </> </シーケンス> <属性name = "id" type = "id" use = "optional"/> </complexType> </element> 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 specify a mandatory and optional to implement SignatureMethod algorithms, user specified algorithms are permitted. Schema Definition:
SignatureValue要素には、デジタル署名の実際の値が含まれています。Base64 [MIME]を使用して常にエンコードされます。SignatureMethodアルゴリズムを実装するための必須およびオプションを指定しますが、ユーザー指定のアルゴリズムが許可されています。スキーマ定義：
<element name="SignatureValue" type="ds:CryptoBinary"/> DTD:
<要素name = "SignatureValue" type = "ds：cryptobinary"/> dtd：
<!ELEMENT SignatureValue (#PCDATA) >
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. Schema Definition:
SignedInfoには、明示的な署名またはダイジェストプロパティ（計算時間、暗号化デバイスのシリアル番号など）は含まれません。アプリケーションがプロパティを署名またはダイジェストに関連付ける必要がある場合、そのような情報をオブジェクト要素内の署名プロパリティ要素に含めることができます。スキーマ定義：
<element name="SignedInfo">
<complexType>
<sequence>
<element ref="ds:CanonicalizationMethod"/>
<element ref="ds:SignatureMethod"/>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/> </complexType> </element> DTD:
<属性name = "id" type = "id" use = "optional"/> </complexType> </element> 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 Canonical XML [XML-C14N] method.
CanonicalizationMethodは、署名計算を実行する前にSigneDINFO要素に適用される正規化アルゴリズムを指定する必須要素です。この要素は、アルゴリズム識別子と実装要件で説明されているアルゴリズムの一般構造を使用します（セクション6.1）。実装は、必要な正規XML [XML-C14N]メソッドをサポートする必要があります。
Alternatives to the REQUIRED Canonical XML algorithm (section 6.5.2), such as Canonical XML with Comments (section 6.5.2) and Minimal Canonicalization (the CRLF and charset normalization specified in section 6.5.1), may be explicitly specified but are NOT REQUIRED. Consequently, their use may not interoperate with other applications that do no 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 minimal or other non-XML aware canonicalization algorithms are not properly constrained (see section 8.2: Only What is "Seen" Should be Signed).
コメント（セクション6.5.2）および最小限の標準化（セクション6.5.1で指定されたCRLFおよび炭化法の正規化）を備えた標準XMLなど、必要な標準XMLアルゴリズム（セクション6.5.2）の代替案（セクション6.5.2）および最小限の標準化（CRLFおよび炭化する正規化）は明示的に指定できますが、必須。したがって、それらの使用は、指定されたアルゴリズムをサポートしない他のアプリケーションと相互運用することはできません（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 the two types of algorithms specified by this document:
SignedInfo要素が標準化法に提示される方法は、その方法に依存します。このドキュメントで指定された2種類のアルゴリズムには、以下が適用されます。
* Canonical XML [XML-C14N] (with or without comments) implementation MUST be provided with an 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 (such that the namespace context and similar ancestor information of the SignedInfo is preserved).
* 標準XML [XML-C14N]（コメントの有無にかかわらず）実装は、SignedInfoを含むドキュメントから元々形成されたXPathノードセットを提供する必要があり、現在SignedInfo、その子孫、およびSignedInfoの属性と名前空間ノードを示しています。子孫要素（名前空間コンテキストとSignedInfoの同様の祖先情報が保存されています）。
* Minimal canonicalization implementations MUST be provided with the 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.
* 最小限の標準化の実装は、最初の文字からXML表現の最後の文字まで、包括的である、よく形成されたSignedInfo要素を表すオクテットで提供する必要があります。これには、SignedInfo要素の開始タグと終了タグのテキスト全体と、それらのタグ間のすべての子孫マークアップおよびキャラクターデータ（つまり、テキスト）が含まれます。
We RECOMMEND that resource constrained applications that do not implement the Canonical XML [XML-C14N] algorithm and instead choose minimal canonicalization (or some other form) be implemented to generate Canonical XML as their output serialization so as to easily mitigate some of these interoperability and security concerns. (While a result might not be the canonical form of the original, it can still be in canonical form.) For instance, such an implementation SHOULD (at least) generate standalone XML instances [XML]. Schema Definition:
標準的なXML [XML-C14N]アルゴリズムを実装しないリソース制約のあるアプリケーションを推奨し、代わりに最小限の標準化（または他の形式）を選択して、標準的なXMLを出力のシリアル化として生成して、これらの相互運用性の一部を簡単に軽減するために生成することをお勧めします。セキュリティ上の懸念。（結果はオリジナルの標準的な形ではないかもしれませんが、それはまだ標準的な形式である可能性があります。）たとえば、そのような実装は（少なくとも）スタンドアロンXMLインスタンス[XML]を生成する必要があります。スキーマ定義：
<element name="CanonicalizationMethod"> <complexType> <sequence> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="uriReference" use="required"/> </complexType> </element> DTD:
<要素name = "CanonicalizationMethod"> <complesType> <sequence> <any namespace = "## any" minoccurs = "0" maxoccurs = "unbounded"/> </sequence> <属性= "algorithm" type = "urireference"use ="必須 "/> </complextype> </element> dtd：
<!ELEMENT CanonicalizationMethod %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. Schema Definition:
SignatureMethodは、署名の生成と検証に使用されるアルゴリズムを指定する必要な要素です。このアルゴリズムは、署名操作に関与するすべての暗号化関数（ハッシュ、公開キーアルゴリズム、MAC、パディングなど）を識別します。この要素は、セクション6.1：アルゴリズムの識別子と実装要件で説明されているアルゴリズムについて、ここで一般構造を使用します。単一の識別子がありますが、その識別子は複数の異なる署名値を含む形式を指定できます。スキーマ定義：
<element name="SignatureMethod">
<complexType>
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Algorithm" type="uriReference" use="required"/>
</complexType>
</element> DTD:
</element> dtd：
<!ELEMENT SignatureMethod %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. Schema Definition:
参照は、1回以上発生する可能性のある要素です。ダイジェストアルゴリズムとダイジェスト値、およびオプションで署名されているオブジェクトの識別子、オブジェクトのタイプ、および/または消化前に適用される変換のリストを指定します。識別（URI）と変換は、消化されたコンテンツ（つまり、消化法への入力）がどのように作成されたかを説明しています。型属性は、参照されるデータの処理を容易にします。たとえば、この仕様は外部データよりも要件を作成していませんが、アプリケーションは指示対象がマニフェストであることを示すことを望む場合があります。オプションのID属性により、参照を他の場所から参照することができます。スキーマ定義：
<element name="Reference"> <complexType> <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="uriReference" use="optional"/> <attribute name="Type" type="uriReference" use="optional"/> </complexType> </element> DTD:
<要素name = "参照"> <complexType> <Sequence> <要素ref = "ds：transforms" minoccurs = "0"/> <要素ref = "ds：digestmethod"/> <要素ref = "ds：digestvalue"/> </sequence> <属性name = "id" type = "id" use = "optional"/> <属性name = "uri" type = "urireference" use = "optional"/> <属性name = "type"type =" urireference "use =" optional "/> </complextype> </element> 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 bytes. 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 byte 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 a 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の代わりにhttp：//www.w3。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 nodesets" 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 a an octet stream and the next transformrequires a node-set, the signature application MUST attempt to parse the octets.
* データオブジェクトがオクテットストリームであり、次のtransformがノードセットを作成する場合、署名アプリケーションはオクテットの解析を試みなければなりません。
* If the data object is a node-set and the next transformrequires octets, the signature application MUST attempt to convert the node-set to an octet stream using the REQUIRED canonicalization algorithm [XML-C14N].
* データオブジェクトがノードセットであり、次のTransformrequiresオクテットである場合、署名アプリケーションは、必要な正規化アルゴリズム[XML-C14N]を使用してノードセットをオクテットストリームに変換しようと試みなければなりません。
Users may specify alternative transforms that over-ride 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 transformthat requires XML parsing is applied (See Transforms (section 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-Referenceが[URI、セクション4.2]で定義されている「同じドキュメント」参照でない限り、URIの参照が拒否された結果はオクテットストリームでなければなりません。特に、URIによって識別されるXMLドキュメントは、URIが同じドキュメントリファレンスである場合、またはXML解析を必要とする変換が適用されない限り、署名アプリケーションによって解析されません（変換（セクション4.3.3.1）を参照）。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 Minimal Canonicalization or Canonical XML with Comments. (Otherwise URI="#foo" will automatically remove comments before the Canonical XML with Comments 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をサポートする必要があります。アプリケーションがコメントで最小限の標準化または標準XMLをサポートする予定の場合は、同じドキュメントXPointers '#xpointer（/）'および '#xpointer（id（ "id"））'のサポートをお勧めします。（それ以外の場合は、uri = "＃foo"は、コメントを備えた標準XMLを呼び出す前にコメントを自動的に削除します。）Xpointersの他のすべてのサポートはオプションです。フラグメントの生成方法について（相互運用性の問題と検証障害につながります）。
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 XML document given its file extension.
uri = "http://example.com/bar.xml"は、外部リソースの「http // example.com/bar.xml」を表すオクテットを識別します。
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 transformrather than a URI fragment (barename XPointer resolution in external resources is not REQUIRED in this specification).
uri = "http://example.com/bar.xml#chapter1" octetとして提供される外部xmlリソース 'http://example.com/bar.xml'のID属性値 'Chapter1'の要素を識別します。ストリーム。繰り返しますが、相互運用性のために、「章1」として識別される要素は、URIフラグメントよりもXPath変換を使用して取得する必要があります（この仕様では、外部リソースのBarename XPointer解像度は必要ありません）。
URI="" Identifies the nodeset (minus any comment nodes) of the XML resource containing the signature
uri = ""署名を含むXMLリソースのノードセット（コメントノードを除いて）を識別します
URI="#chapter1" Identifies a nodeset containing the element with ID attribute value 'chapter1' of the XML resource containing the signature. XML Signature (and its applications) modify this nodeset to include the element plus all descendents including namespaces and attributes -- but not comments.
uri = "＃Chapter1"は、署名を含むXMLリソースのID属性値「Chapter1」を持つ要素を含むノードセットを識別します。XML署名（およびそのアプリケーション）は、このノードセットを変更して、要素と名前空間や属性を含むすべての子孫を含むがコメントではない。
Dereferencing a same-document reference MUST result in an XPath node-set suitable for use by Canonical XML. 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:
同じドキュメントの参照を繰り返すと、標準XMLが使用するのに適した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。Element Node 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は、下位ノードの存在下のノードのセットとしてノードセットを処理するため、Xpointerは通常、XMLドキュメントの解析ツリーのサブツリーを示すため、必要です。標準形式からの代表的なテキストがない場合になります。
The last step is performed for null URIs, barename XPointers and child sequence XPointers. 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に対して実行されます。識別子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).)
各変換は、特定のアルゴリズムに適したアルゴリズム属性とコンテンツパラメーターで構成されています。アルゴリズム属性値は、実行するアルゴリズムの名前を指定し、変換コンテンツはアルゴリズムの変換入力の処理を管理する追加データを提供します。（アルゴリズム識別子と実装要件（セクション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）で説明されているように、一部の変換はXPathノードセットを入力として取りますが、他の変換ではオクテットストリームが必要です。実際の入力が変換の入力ニーズと一致する場合、変換は変更されていない入力で動作します。変換入力要件が実際の入力の形式と異なる場合、入力を変換する必要があります。
Some Transform 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) defines the list of standard transformations. Schema Definition:
変換の例には、Base64デコード[MIME]、CanOnicalization [XML-C14N]、XPathフィルタリング[XPath]、およびXSLT [XSLT]が含まれますが、これらに限定されません。変換要素の汎用定義は、アプリケーション固有の変換アルゴリズムも可能にします。たとえば、変換は、Java変換アルゴリズムにbase64エンコードされたパラメーターとして表示されるJavaクラスによって与えられる減圧ルーチンになる可能性があります。ただし、アプリケーションドメインの外で署名を検証できるようにしたい場合は、アプリケーション固有の変換の使用を控える必要があります。変換アルゴリズム（セクション6.6）は、標準変換のリストを定義します。スキーマ定義：
<element name="Transforms">
<complexType>
<sequence>
<element ref="ds:Transform" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="Transform"> <complexType> <choice maxOccurs="unbounded"> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <element name="XSLT" type="string"/> <!-- should be an xsl:stylesheet element --> <element name="XPath" type="string"/> </choice> <attribute name="Algorithm" type="uriReference" use="required"/> </complexType> </element> DTD:
<要素name = "Transform"> <complexType> <choice maxoccurs = "unbounded"> <any namespace = "## other" processcontents = "lax" minoccurs = "0" maxoccurs = "xslt "type =" string "/> <！ - xsl：styleSheet要素である必要があります - > <要素name =" xpath "type =" string "/> </choice> <属性name =" algorithm "type = =「urireference」use = "必須"/> </complextype> </element> dtd：
<!ELEMENT Transforms (Transform+)>
<!ELEMENT Transform %Transform.ANY; >
<!ATTLIST Transform
Algorithm CDATA #REQUIRED >
<!ELEMENT XPath (#PCDATA) >
<!ELEMENT XSLT (#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 Minimal Canonicalization or Canonical XML with Comments was specified in the Transforms). The digest algorithm is applied to the data octets of the resulting octet stream. Schema Definition:
URIの規制と変換の適用の結果がXPathノードセット（またはアプリケーションによって実装された十分に機能的な置換）である場合、参照処理モデル（セクション4.3.3.2）で説明されているように変換する必要があります。URIの規制と変換の適用の結果がOctetストリームである場合、変換は発生しません（変換でコメントを備えた最小限の標準化または標準XMLが指定された場合、コメントが存在する可能性があります）。ダイジェストアルゴリズムは、結果のオクテットストリームのデータオクテットに適用されます。スキーマ定義：
<element name="DigestMethod"> <complexType> <sequence> <any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="uriReference" use="required"/> </complexType> </element> DTD:
<要素name = "digestmethod"> <complextype> <sequence> <any namespace = "## any" processcontents = "lax" minoccurs = "0" maxoccurs = "unbounded"/> </sequence> <属性name = "algorithm"type =" urireference "use ="必須 "/> </complextype> </element> dtd：
<!ELEMENT DigestMethod %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]. Schema Definition:
DigestValueは、Digestのエンコードされた値を含む要素です。ダイジェストは、Base64 [Mime]を使用して常にエンコードされます。スキーマ定義：
<element name="DigestValue" type="ds:CryptoBinary"/> DTD:
<要素name = "digestvalue" type = "ds：cryptobinary"/> 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 place their own key identification and exchange semantics within this element type through the XML-namespace facility [XML-ns].
KeyInfoは、受信者が署名を検証するために必要なキーを取得できるようにするオプションの要素です。KeyINFOには、帯域内のキー配布や主要な契約データなど、キー、名前、証明書、およびその他の公開キー管理情報が含まれる場合があります。この仕様ではいくつかの簡単なタイプを定義しますが、アプリケーションは、XML-NamesSpace Facility [XML-NS]を介して、この要素タイプ内に独自の重要な識別と交換セマンティクスを配置する場合があります。
If KeyInfo is omitted, the recipient is expected to be able to identify the key based on application context information. 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）を実装する必要があり、取得valmethod（セクション4.4.3）を実装する必要があります。
The following list summarizes the KeyInfo types defined by this specification; these can be used within the RetrievalMethod Type attribute to describe the remote KeyInfo structure as represented as an octect stream.
次のリストは、この仕様で定義されたKeyINFOタイプをまとめたものです。これらは、retirevalMethod型属性内で使用して、オクタクトストリームとして表されるリモートKeyINFO構造を記述できます。
* 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#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
In addition to the types above for which we define structures, we specify one additional type to indicate a binary X.509 Certificate
構造を定義する上記のタイプに加えて、バイナリX.509証明書を示すために1つの追加タイプを指定します
* http://www.w3.org/2000/09/xmldsig#rawX509Certificate
* http://www.w3.org/2000/09/xmldsig#rawX509Certificate
Schema Definition:
スキーマ定義：
<element name="KeyInfo"> <complexType> <choice maxOccurs="unbounded"> <any processContents="lax" namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <element name="KeyName" type="string"/> <element ref="ds:KeyValue"/> <element ref="ds:RetrievalMethod"/> <element ref="ds:X509Data"/> <element ref="ds:PGPData"/> <element ref="ds:SPKIData"/> <element name="MgmtData" type="string"/> </choice> <attribute name="Id" type="ID" use="optional"/> </complexType> </element> DTD:
<要素name = "keyInfo"> <complexType> <choice maxoccurs = "unbounded"> <any processcontents = "lax" namespace = "## other" minoccurs = "0" maxoccurs = "unbounded"/> <要素name = "keyname "type =" string "/> <要素ref =" ds：keyvalue "/> <rement ref =" ds：retirevalmethod "/> <要素ref =" ds：x509data "/> <要素ref =" ds：pgpdata"/> <要素ref =" ds：spkidata "/> <element name =" mgmtdata "type =" string "/> </choice> <属性name =" id "type =" id "use =" optional "/> </complexType> </element> dtd：
<!ELEMENT KeyInfo %Key.ANY; >
<!ATTLIST KeyInfo
Id ID #IMPLIED >
The KeyName element contains a string value 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.) Schema Definition:
KeyName要素には、署名者がキー識別子を受信者に伝えるために使用できる文字列値が含まれています。通常、KeyNameにはメッセージの署名に使用されるキーペアに関連する識別子が含まれていますが、間接的にキーペアを識別する他のプロトコル関連情報が含まれている場合があります。（KeyNameの一般的な用途には、キーの単純な文字列名、キーインデックス、著名な名前（DN）、電子メールアドレスなど）スキーマ定義が含まれます。
<!-- type declared in KeyInfo --> DTD:
<！ - keyinfoで宣言されたタイプ - > 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). Schema Definition:
KeyValue要素には、署名の検証に役立つ単一の公開キーが含まれています。DSA（必須）およびRSA（推奨）を定義するための構造化された形式は、署名アルゴリズム（セクション6.4）で定義されています。スキーマ定義：
<element name="KeyValue">
<complexType mixed="true">
<choice>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="ds:DSAKeyValue"/>
<element ref="ds:RSAKeyValue"/>
</choice>
</complexType>
</element>
DTD:
<!ELEMENT KeyValue %Key.ANY; >
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. Note, if the result of dereferencing and transforming the specified URI is a node set, then it may need to be to be canonicalized. All of the KeyInfo types defined by this specification (section 4.4) represent octets, consequently the Signature application is expected to attempt to canonicalize the nodeset via the The Reference Processing Model (section 4.3.3.2)
retrievalMethodは、参照のURI（セクション4.3.3.1）および参照処理モデル（セクション4.3.3.2）と同じ構文と逆方向の動作を使用します。注意して、指定されたURIがノードセットであると述べて変換された場合、正規化する必要がある場合があります。この仕様（セクション4.4）で定義されたすべてのKeyINFOタイプはオクテットを表しています。その結果、署名アプリケーションは、参照処理モデル（セクション4.3.3.2）を介してノードセットを正規化しようと予想されます。
Type is an optional identifier for the type of data to be retrieved. Schema Definition
タイプは、取得するデータのタイプのオプションの識別子です。スキーマ定義
<element name="RetrievalMethod">
<complexType>
<sequence>
<element ref="ds:Transforms" minOccurs="0"/>
</sequence>
<attribute name="URI" type="uriReference"/>
<attribute name="Type" type="uriReference" use="optional"/>
</complexType>
</element>
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 revocation lists). Five types of X509Data are defined
KeyInfo内のX509DATA要素には、キーまたはX509証明書（または証明書の識別子または取り消しリスト）の1つ以上の識別子が含まれています。5種類のX509DATAが定義されています
1. The X509IssuerSerial element, which contains an X.509 issuer distinguished name/serial number pair that SHOULD be compliant with RFC2253 [LDAP-DN], 2. The X509SubjectName element, which contains an X.509 subject distinguished name that SHOULD be compliant with RFC2253 [LDAP-DN], 3. The X509SKI element, which contains an X.509 subject key identifier value. 4. The X509Certificate element, which contains a base64-encoded [X509v3] certificate, and 5. The X509CRL element, which contains a base64-encoded certificate revocation list (CRL) [X509v3].
1. X.509 IssuerSerial Elementには、RFC2253 [LDAP-DN]、2に準拠する必要があるX.509発行者の著名な名前/シリアル番号ペアが含まれています。[LDAP-DN]、3。X.509サブジェクトキー識別子値を含むX509SKI要素。4. base64エンコード[x509v3]証明書を含むx509certificate要素と5. base64エンコードされた証明書取消リスト（CRL）[x509v3]を含むx509crl要素。
Multiple declarations about a single certificate (e.g., a X509SubjectName and X509IssuerSerial element) MUST be grouped inside a single X509Data element; multiple declarations about the same key but different certificates (related to that single key) MUST be grouped within a single KeyInfo element but MAY occur in multiple X509Data elements. For example, the following block contains two pointers to certificate-A (issuer/serial number and SKI) and a single reference to certificate-B (SubjectName) and also shows use of certificate elements
単一の証明書に関する複数の宣言（例：X509SubjectNameおよびX509ISSUERSERIAL要素）は、単一のX509DATA要素内にグループ化する必要があります。同じキーが異なるが異なる証明書（その単一キーに関連する）についての複数の宣言は、単一のKeyINFO要素内でグループ化する必要がありますが、複数のX509DATA要素で発生する場合があります。たとえば、次のブロックには、証明書A（発行者/シリアル番号とスキー）への2つのポインターと証明書B（件名）への単一の参照が含まれており、証明書要素の使用も示しています。
<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> <!-- certificate chain -->
<!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
<X509Certificate>MIICXTCCA..</X509Certificate>
<!-- Intermediate cert subject CN=arbolCA,OU=FVTO=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 or a CRL 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. Schema Definition
注意してください、証明書またはCRLの「バッグ」をエンコードしたPKCS＃7の直接的な規定はありません。ただし、X509DATA要素内で一連の証明書またはCRLが発生する可能性があり、keyInfoで複数のx509Data要素が発生する可能性があります。X509DATA要素で複数の証明書が発生する場合はいつでも、少なくとも1つのそのような証明書には、署名を検証する公開キーを含める必要があります。スキーマ定義
<element name="X509Data">
<complexType>
<choice>
<sequence maxOccurs="unbounded">
<choice>
<element ref="ds:X509IssuerSerial"/>
<element name="X509SKI" type="ds:CryptoBinary"/>
<element name="X509SubjectName" type="string"/>
<element name="X509Certificate" type="ds:CryptoBinary"/>
</choice>
</sequence>
<element name="X509CRL" type="ds:CryptoBinary"/>
</choice>
</complexType>
</element>
<element name="X509IssuerSerial">
<complexType>
<sequence>
<element name="X509IssuerName" type="string"/>
<element name="X509SerialNumber" type="integer"/>
</sequence>
</complexType>
</element>
DTD
DTD
<!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
X509Certificate)+ | X509CRL)>
<!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
<!ELEMENT X509IssuerName (#PCDATA) >
<!ELEMENT X509SubjectName (#PCDATA) >
<!ELEMENT X509SerialNumber (#PCDATA) >
<!ELEMENT X509SKI (#PCDATA) >
<!ELEMENT X509Certificate (#PCDATA) >
<!ELEMENT X509CRL (#PCDATA) >
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 string 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]. Other sub-types of the PGPData element may be defined by the OpenPGP working group. Schema Definition:
KeyInfo内のPGPDATA要素は、そのようなキーのPGP公開キーのペアと署名に関連する情報を伝えるために使用されます。PGPKEYIDの値は、[PGP、セクション11.2]で定義されている標準のPGP公開キー識別子を含む文字列です。PGPKEYPACKETには、[PGP、セクション5.5]で定義されているBase64エンコードされたキーマテリアルパケットが含まれています。PGPDATA要素の他のサブタイプは、OpenPGPワーキンググループによって定義される場合があります。スキーマ定義：
<element name="PGPData">
<complexType>
<choice>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<sequence>
<element name="PGPKeyID" type="string"/>
<element name="PGPKeyPacket" type="ds:CryptoBinary"/>
</sequence>
</choice>
</complexType>
</element>
DTD:
DTD：
<!ELEMENT PGPData (PGPKeyID, PGPKeyPacket) >
<!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. The content of this element type is expected to be a Canonical S-expression. Schema Definition:
KeyInfo内のSpkidata要素は、SPKIの公開キーペア、証明書、その他のSPKIデータに関連する情報を伝えるために使用されます。この要素タイプの含有量は、標準的なS発現であると予想されます。スキーマ定義：
<element name="SPKIData" type="string"/> DTD:
<要素name = "spkidata" type = "string"/> dtd：
<!ELEMENT SPKIData (#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. Schema Definition:
KeyInfo内のMGMTDATA要素は、帯域内のキーディストリビューションまたは契約データを伝達するために使用される文字列値です。たとえば、DHキーエクスチェンジ、RSAキー暗号化など。スキーマ定義：
<!-- type declared in KeyInfo --> DTD:
<！ - keyinfoで宣言されたタイプ - > 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 MimeType attribute is an optional attribute which describes the data within the Object. This is a string with values defined by [MIME]. For example, if the Object contains XML, the MimeType could be text/xml. This attribute is purely advisory; no validation of the MimeType information is required by this specification.
MIMETYPE属性は、オブジェクト内のデータを記述するオプションの属性です。これは、[mime]で定義された値を持つ文字列です。たとえば、オブジェクトにXMLが含まれている場合、MIMETYPEはテキスト/XMLである可能性があります。この属性は純粋にアドバイザリーです。この仕様では、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またはマニフェストのリファレンスから参照されます。この要素は通常、署名されているオブジェクトが署名要素に含まれる署名の包囲に使用されます。ダイジェストは、開始タグとエンドタグを含むオブジェクト要素全体にわたって計算されます。
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を提供するために使用できます。
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. Schema Definition:
注アプリケーションがダイジェスト計算から<オブジェクト>タグを除外したい場合、参照は実際のデータオブジェクト（XMLドキュメントで簡単）を識別する必要があります。-xml）。データオブジェクトが署名内から署名（または逆）に移動された場合、またはオブジェクトのコンテンツがエンコードである場合、データオブジェクトが署名内から移動している場合、署名が有効なままである場合、オブジェクトタグの除外が望ましい場合があります。元のバイナリ文書であり、元のビットワイズ表現に署名するように抽出およびデコードすることが望まれます。スキーマ定義：
<element name="Object">
<complexType mixed="true">
<sequence maxOccurs="unbounded">
<any namespace="##any" processContents="lax"/>
</sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="MimeType" type="string" use="optional"/> <!-- add a grep facet --> <attribute name="Encoding" type="uriReference" use="optional"/> </complexType> </element> DTD:
</sequence> <属性name = "id" type = "id" use = "optional"/> <属性name = "mimetype" type = "string" use = "optional"/> <！ - grep facetを追加 - > <属性name = "encoding" type = "urireference" use = "optional"/> </complexType> </element> dtd：
<!ELEMENT Object %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処理の指示とコメントの処理について説明します。要素に関して、マニフェストおよびSignaturePropertiesこのセクションは、構文と小さな動作を指定します - アプリケーションに任されています。これらの要素は、親のコンテンツモデルが許す場所に表示できます。署名コンテンツモデルは、オブジェクト内でのみ許可します。
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. Schema Definition:
マニフェスト要素は、参照のリストを提供します。SignedInfoのリストとの違いは、それが定義されたアプリケーションであることです。これは、もしあれば、Digestが実際に参照されたオブジェクトに対してチェックされ、オブジェクトがアクセスできないか、ダイジェストの比較が失敗した場合に何をするかです。マニフェストがSignedinfoから指されている場合、マニフェストのダイジェスト自体がコア署名検証動作によってチェックされます。このようなマニフェスト内のダイジェストは、アプリケーションの裁量でチェックされます。マニフェストが別のマニフェストから参照されている場合、この2つのレベルの深いマニフェストの全体的なダイジェストでさえチェックされない可能性があります。スキーマ定義：
<element name="Manifest">
<complexType>
<sequence>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> </element> DTD:
</sequence> <属性name = "id" type = "id" use = "optional"/> </complextype> </element> 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">
<complexType>
<sequence>
<element ref="ds:SignatureProperty" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
</element>
<element name="SignatureProperty"> <complexType mixed="true"> <choice minOccurs="0" maxOccurs="unbounded"> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </choice> <attribute name="Target" type="uriReference" use="required"/> <attribute name="Id" type="ID" use="optional"/> </complexType> </element> DTD:
<要素name = "SignatureProperty"> <complexType Mixed = "true"> <choice minoccurs = "0" maxoccurs = "unbounded"> <any namespace = "## other" processcontents = "lax" minoccurs = "0" maxoccurs ="Unbounded"/> </choice> <属性name = "ターゲット" type = "urireference" use = "expect"/> <属性name = "id" type = "id" use = "optional"/> </complextype> </element> dtd：
<!ELEMENT SignatureProperties (SignatureProperty+) >
<!ATTLIST SignatureProperties
Id ID #IMPLIED >
<!ELEMENT SignatureProperty %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 specified 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、および実装の要件を定義します。要件は、署名使用の要件を超えてではなく、実装よりも指定されています。さらに、メカニズムは拡張可能であり、代替アルゴリズムは署名アプリケーションで使用できます。
(Note that the normative identifier is the complete URI in the table though they are sometimes abbreviated in XML syntax (e.g., "&dsig;base64").)
（規範識別子はテーブルの完全なURIであることに注意してください。ただし、XML構文で略されることがあります（例： "＆dsig; base64"）。）
Algorithm Type
Algorithm - Requirements - Algorithm URI
Digest
SHA1 - REQUIRED - &dsig;sha1
Encoding
base64 - REQUIRED - &dsig;base64
MAC
HMAC-SHA1 - REQUIRED - &dsig;hmac-sha1
Signature
DSAwithSHA1(DSS) - REQUIRED - &dsig;dsa-sha1
RSAwithSHA1 - RECOMMENDED - &dsig;rsa-sha1
Canonicalization
minimal - RECOMMENDED - &dsig;minimal
Canonical XML with Comments - RECOMMENDED -
http://www.w3.org/TR/2000/CR-xml-c14n-20001026#WithComments
Canonical XML (omits comments) - REQUIRED -
http://www.w3.org/TR/2000/CR-xml-c14n-20001026
Transform
XSLT - OPTIONAL - http://www.w3.org/TR/1999/REC-xslt-19991116
XPath - RECOMMENDED -
http://www.w3.org/TR/1999/REC-xpath-19991116
Enveloped Signature* - REQUIRED - &dsig;enveloped-signature
* 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 cryptography 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:
<DigestMethod Algorithm="&dsig;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: A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
SHA-1ダイジェストは160ビット文字列です。DigestValue要素の内容は、20オクテットのOctetストリームと見なされるこのビット文字列のbase64エンコードでなければなりません。たとえば、メッセージダイジェストのダイジェストバリュー要素：A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be:
<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="&dsig;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
9294727A 3638BB1C 13F48EF8 158BFC9D
9294727a 3638bb1c 13f48ef8 158bfc9d
from the test vectors in [HMAC] would be
[hmac]のテストベクトルから
<SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue> Schema Definition:
<SignatureValue> kpryejy4uxwt9i74fyv8nq == </signaturevalue>スキーマ定義：
<element name="HMACOutputLength" type="integer"/> DTD:
<要素name = "hmacoutputlength" type = "integer"/> 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="&dsig;dsa"/>
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. Integer to octet-stream conversion must be done according to the I2OSP operation defined in the RFC 2437 [PKCS1] specification with a k parameter equal to 20. For example, the SignatureValue element for a DSA signature (r, s) with values specified in hexadecimal:
DSAアルゴリズムの出力は、通常ペア（r、s）で言及される整数のペアで構成されています。署名値は、値rとsのオクテットエンコードに起因する2つのオクテットストリームの連結のbase64エンコードで構成されています。オクテットストリームへの変換への整数は、20に等しいKパラメーターを使用してRFC 2437 [PKCS1]仕様で定義されたI2OSP操作に従って行う必要があります。：
r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8 from the example in Appendix 5 of the DSS standard would be
R = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 S = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
<SignatureValue>
i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==</SignatureValue>
DSA key values have the following set of fields: P, Q, G and Y are mandatory when appearing as a key value, J, seed and pgenCounter are optional but should be present. (The seed and pgenCounter fields must appear together or be absent). All parameters are encoded as base64 [MIME] values. Schema:
DSAキー値には、次のフィールドセットがあります。キー値として表示される場合は、P、Q、G、Yが必須です。J、シード、PGENCカウンターはオプションですが、存在する必要があります。（種子とPGENCounterのフィールドは一緒に現れるか、存在しない必要があります）。すべてのパラメーターは、base64 [mime]値としてエンコードされます。スキーマ：
<element name="DSAKeyValue"> <complexType> <sequence> <sequence> <element name="P" type="ds:CryptoBinary"/> <element name="Q" type="ds:CryptoBinary"/> <element name="G" type="ds:CryptoBinary"/> <element name="Y" type="ds:CryptoBinary"/> <element name="J" type="ds:CryptoBinary" minOccurs="0"/> </sequence> <sequence minOccurs="0"> <element name="Seed" type="ds:CryptoBinary"/> <element name="PgenCounter" type="ds:CryptoBinary"/> </sequence> </sequence> </complexType> </element> DTD:
<要素name = "dsakeyvalue"> <complextype> <sequence> <sequence> <要素name = "p" type = "ds：cryptobinary"/> <要素name = "q" type = "ds：cryptobinary"/> <要素名= "g" type = "ds：cryptobinary"/> <要素name = "y" type = "ds：cryptobinary"/> <要素name = "j" type = "ds：cryptobinary" minoccurs = "0" "/> </sequence> <sequence minoccurs = "0"> <要素name = "seed" type = "ds：cryptobinary"/> <要素name = "pgencounter" type = "ds：cryptobinary"/> </sequence></sequence> </complexType> </element> 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: http://www.w3.org/2000/09/xmldsig#rsa-sha1
識別子：http：//www.w3.org/2000/09/xmldsig#rsa-sha1
Arbitrary-length integers (e.g., "bignums" such as RSA modulii) are represented 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 even number of bytes). If the bitstring contains entire leading bytes that are zero, these are removed (so the high-order byte 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).
任意の長さの整数（例：RSA moduliiなどの「ビグノム」）は、XMLでオクテットの弦として表されます。整数値は、最初に「ビッグエンディアン」ビットストリングに変換されます。次に、ビットストリングには、ビットの総数== 0 mod 8（偶数バイトがあるように）のゼロビットでパディングされます。ビットストリングにゼロの先頭バイト全体が含まれている場合、これらは削除されます（したがって、高次バイトは常にゼロではありません）。このオクテット文字列は、base64 [mime]エンコードされます。（整数からOctet弦への変換は、長さが最小限のIEEE 1363のI2OSP [1363]と同等です）。
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: <SignatureMethod Algorithm="&dsig;rsa-sha1"/>
このドキュメントで使用されている「RSAアルゴリズム」という式は、RFC 2437 [PKCS1]で説明されているRSASSA-PKCS1-V1_5アルゴリズムを指します。RSAアルゴリズムは明示的なパラメーターを取得しません。RSA SignatureMethod要素の例は次のとおりです。
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 is 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 concatentation, "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>IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4
t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
</SignatureValue>
RSA key values have two fields Modulus and Exponent
RSAキー値には、2つのフィールドモジュラスと指数があります
<RSAKeyValue>
<rsakeyvalue>
<Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
Schema:
スキーマ：
<element name="RSAKeyValue"> <complexType> <sequence> <element name="Modulus" type="ds:CryptoBinary"/> <element name="Exponent" type="ds:CryptoBinary"/> </sequence> </complexType> </element> DTD:
<要素name = "rsakeyvalue"> <complexType> <sequence> <要素name = "modulus" type = "ds：cryptobinary"/> <element name = "exponent" type = "ds：cryptobinary"/> </sequence> </sequence></complexType> </element> dtd：
<!ELEMENT RSAKeyValue (Modulus, Exponent) >
<!ELEMENT Modulus (#PCDATA) >
<!ELEMENT Exponent (#PCDATA) >
If canonicalization is performed over octets, the canonicalization algorithms take two implicit parameter: 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.
標準化がオクテットを介して実行される場合、標準化アルゴリズムは、コンテンツとそのcharsetという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]. 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]中にテキスト正規化を実行します。外部で指定された標準化アルゴリズムが同じことを行うことをお勧めします。（既存の充電器をUnicodeに変換することにはあいまいなことがあります。たとえば、XML日本のプロファイル[XML-Japanese]注を参照してください。）
Identifier: http://www.w3.org/2000/09/xmldsig#minimal
識別子：http：//www.w3.org/2000/09/xmldsig#minimal
An example of a minimal canonicalization element is:
<CanonicalizationMethod Algorithm="&dsig;minimal"/>
The minimal canonicalization algorithm:
最小限の標準化アルゴリズム：
* converts the character encoding to UTF-8 (without any byte order mark (BOM)). If an encoding is given in the XML declaration, it must be removed. Implementations MUST understand at least [UTF-8] and [UTF-16] as input encodings. Non-Unicode to Unicode transcoding MUST perform text normalization [NFC].
* normalizes line endings as provided by [XML]. (See XML and Canonicalization and Syntactical Considerations (section 7).)
*エンコードをUTF-8に変換します（バイトオーダーマーク（BOM）なし）。XML宣言でエンコーディングが与えられている場合、削除する必要があります。実装は、少なくとも[UTF-8]および[UTF-16]を入力エンコーディングとして理解する必要があります。ユニコードからユニコードトランスコーディングは、テキスト正規化[NFC]を実行する必要があります。
* [XML]で提供されているように、ラインエンディングを正規化します。（XMLおよび標準化および構文的な考慮事項（セクション7）を参照してください。）
This algorithm requires as input the octet stream of the resource to be processed; the algorithm outputs an octet stream. When used to canonicalize SignedInfo the algorithm MUST be provided with the octets that represent the well-formed SignedInfo element (and its children and content) as described in The CanonicalizationMethod Element (section 4.3.1).
このアルゴリズムには、処理するリソースのオクテットストリームを入力する必要があります。アルゴリズムはオクテットストリームを出力します。signedInfoの正規化に使用する場合、標準化されたmethod要素（セクション4.3.1）に記載されているように、よく形成されたsignedinfo要素（およびその子供とコンテンツ）を表すオクテットをアルゴリズムに提供する必要があります。
If the signature application has a node set, then the signature application must convert it into octets as described in The Reference Processing Model (section 4.3.3.2). However, Minimal Canonicalization is NOT RECOMMENDED for processing XPath node-sets, the results of same-document URI references, and the output of other types of XML based transforms. It is only RECOMMENDED for simple character normalization of well formed XML that has no namespace or external entity complications.
署名アプリケーションにノードセットがある場合、参照処理モデル（セクション4.3.3.2）で説明されているように、署名アプリケーションをオクテットに変換する必要があります。ただし、XPathノードセット、同じドキュメントURI参照の結果、および他のタイプのXMLベースの変換の出力の処理には、最小限の標準化は推奨されません。名前空間または外部エンティティの合併症を持たない適切に形成されたXMLの単純な文字正規化にのみ推奨されます。
Identifier for REQUIRED Canonical XML (omits comments): http://www.w3.org/TR/2000/CR-xml-c14n-20001026
必要な正規XMLの識別子（コメントを省略）：http：//www.w3.org/tr/2000/cr-xml-c14n-20001026
Identifier for Canonical XML with Comments: http://www.w3.org/TR/2000/CR-xml-c14n-20001026#WithComments
コメント付き標準XMLの識別子：http：//www.w3.org/tr/2000/cr-xml-c14n-20001026#withcomments
An example of an XML canonicalization element is:
XML Canonicalization Elementの例は次のとおりです。
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-
c14n-20001026"/>
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 parameters: 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 base 64 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.
ベース64デコード変換の規範的仕様は[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ノードセットである場合、コメントノードは省略されていることに注意してください。実際の入力がオクテットストリームの場合、アプリケーションは、コメントを使用して標準XMLが使用するのに適したXPathノードセットにオクテットストリームを変換する必要があります（必要な正規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に初期化されたコンテキスト位置。
* 1に初期化されたコンテキストサイズ。
* Xpathで定義されている関数セットとここで指定された関数に等しい関数のライブラリ。
*可変バインディングのセット。これらを初期化するための手段は定義されていません。したがって、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 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]で使用されるものと非常に類似しています。ノード（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式が表示されない場合、エラーが発生します。
Note: The function definition for here() is intended to be consistent with its definition in XPointer. However, some minor differences are presently being discussed between the Working Groups.
注：ここ（）の関数定義は、Xpointerでの定義と一致することを目的としています。ただし、現在、ワーキンググループ間でいくつかの小さな違いが議論されています。
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="&dsig;">
<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. 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変換の要件と同じです。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]. The XSL style sheet or transform to be evaluated appears as the character content of a transform parameter child element named XSLT. The root element of a XSLT style sheet SHOULD be <xsl:stylesheet>.
XSL変換の規範的仕様は[XSLT]です。評価されるXSLスタイルシートまたは変換は、XSLTという名前の変換パラメーター子要素の文字コンテンツとして表示されます。XSLTスタイルシートのルート要素は<XSL：Stylesheet>でなければなりません。
This transform requires an octet stream as input. If the actual input is an XPath node-set, then the signature application should attempt to covert 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 transformauthors 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 transformafter the XSLT transformto perform 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 TransformAuthorsは、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 three 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. And, 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.
標準化する必要があるXMLの変化の種類は、3つのカテゴリに分割できます。以下7.1で説明されているように、基本[XML]に関連するものがあります。以下の7.2で説明されているように、[dom]、[sax]、または同様の処理に関連するものがあります。そして、第三に、UTF-8とUTF-16の間など、コード化された文字セット変換の可能性があります。
Any canonicalization algorithm should yield output in a specific fixed coded character set. For both the minimal canonicalization defined in this specification and Canonical XML [XML-C14N] that coded character set is UTF-8 (without a byte order mark (BOM)).Neither the minimal canonicalization nor the Canonical XML [XML-C14N] algorithms provide character normalization. We RECOMMEND that signature applications create XML content (Signature elements and their descendents/content) in Normalization Form C [NFC] 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 [XML-C14N]の両方について。最小限の標準化も標準XML [XML-C14N]アルゴリズムも文字の正規化を提供します。署名アプリケーションは、正規化フォームC [NFC]でXMLコンテンツ（署名要素とその子孫/コンテンツ）を作成することをお勧めし、消費されている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,
XML 1.0 [XML]は、XMLを読み取る適切なアプリケーションに他の情報ではなく、そのXMLから特定の情報が与えられるインターフェイスを定義します。特に、
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,
1. ラインエンディングは、＃XAがすぐに#XAが続き、他のすべてのケースで＃XAに置き換える場合、#XD文字をドロップすることにより、単一の文字#XAに正規化されます。デフォルト値が存在する場合、3。文字参照は対応する文字に置き換えられます、
4. entity references are replaced with the corresponding declared entity, 5. attribute values are normalized by A. replacing character and entity references as above, B. replacing occurrences of #x9, #xA, and #xD with #x20 (space) except that the sequence #xD#xA is replaced by a single space, and
4. エンティティ参照は、対応する宣言されたエンティティ、5に置き換えられます。5。属性値はAによって正規化されます。シーケンス＃XD＃XAは単一のスペースに置き換えられ、
C. 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.
C.属性がCDATAであると宣言されていない場合、すべてのリーディングスペースとトレーリングスペースを剥ぎ取り、すべての内部の空間を単一のスペースに置き換えます。
Note that items (2), (4), and (5C) 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）、および（5c）は、スキーマ、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 the 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 XML1.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 octect stream that was signed.
XML署名がDOMまたはSAX処理を使用してシステムで生成または検証される場合、DOMツリーの関連部分またはSAXイベントのシーケンスをシリアル化するために標準的な方法が必要です。[XML-C14N]などのXML Canonicalization仕様は、DOMとSAXによって保存されている情報のみに基づいています。XML署名がDOMまたはSAXを使用した実装によって検証可能である場合、前のセクションで指定されたXML1.0構文の制約を追跡する必要があるだけでなく、適切なXML標準化を指定して、検証者がDOM/SAXを再統合できるように指定する必要があります。署名されたのと同じOctectストリームへの媒介入力。
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 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 application 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 can not rely upon canonicalization to do this for them.
Canonical XML [XML-C14N]の使用により、すべての内部エンティティとXMLネームスペースが署名されているコンテンツ内で拡張されるようにすることに注意してください。すべてのエンティティは定義に置き換えられ、標準形式は要素が継承する名前空間を明示的に表します。XMLコンテンツ（特にSignedInfo要素）を正規化しないアプリケーションは、内部エンティティを使用してはならず、署名されているコンテンツ内の名前空間を明示的に表す必要があります。
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 it "sees," persons and automated mechanisms 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 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 as 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. Consequently, while we RECOMMEND all documents operated upon and generated by signature applications be in [NFC] (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.
一部のアプリケーションは、元のデータまたは中間データに対して動作する場合がありますが、元のデータと変換されたデータの間に導入された潜在的な弱点に非常に注意する必要があります。これは、アプリケーションが注意して行う必要がある変換の性格と意味に関する信頼の決定です。文字ケース（下から上から上）または文字組成（「eおよびアクセント」から「アクセント-e」）を正規化する正規化アルゴリズムを考えてください。敵は、正規化された変更を導入し、その結果、署名の妥当性に取るに足らないが、DOMプロセッサに材料を導入することができます。たとえば、キャラクターのケースを変更することにより、Xpath選択の結果に影響を与える可能性があります。その変更が署名検証のために正規化されているが、プロセッサは元のデータで動作し、意図したものとは異なる結果を返す場合、深刻なリスクが導入されます。その結果、署名アプリケーションによって操作および生成されるすべてのドキュメントを推奨しますが、[NFC]（それ以外の場合は中間プロセッサが署名を意図せずに破る可能性があります）に署名変換の一部として実行されるべきではありません。正規化が発生した場合、アプリケーションは常に正規化されたフォームを「操作」（操作する）必要があります。
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/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd Valid XML schema instance based on the 20000922 Schema/DTD [XML-Schema].
XML Signature Schema Instance http://www.w3.org/tr/2000/cr-xmldsig-core-20001031/xmldsig-core-schema.xsd有効なxmlスキーマインスタンス20000922スキーマ/DTD [XML-Schema]に基づく。
XML Signature DTD http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.dtd
XML署名DTD http://www.w3.org/tr/2000/cr-xmldsig-core-20001031/xmldsig-core-schema.dtd
RDF Data Model http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-datamodel-20000112.gif
RDFデータモデルhttp://www.w3.org/tr/2000/cr-xmldsig-core-20001031/xmldsig-datamodel-20012.gif
XML Signature Object Example http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/signature-example.xml A cryptographical invalid XML example that includes foreign content and validates under the schema. (It validates under the DTD when the foreign content is removed or the DTD is modified accordingly).
XML署名オブジェクトの例http://www.w3.org/tr/2000/cr-xmldsig-core-20001031/signature-example.xmlは、スキーマの下で外来コンテンツを含み、検証する暗号化された無効なXML例です。（外部コンテンツが削除された場合、またはDTDがそれに応じて変更された場合、DTDの下で検証します）。
RSA XML Signature Example http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/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/tr/2000/cr-xmldsig-core-20001031/signature-example-rsa.xmlは、メルリン・ヒューズが生成された暗号値を備えたXML署名の例で、グレゴール・カリンガーによって検証されました。
DSA XML Signature Example http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/signature-example-dsa.xml Similar to above but uses DSA.
DSA XML署名の例http://www.w3.org/tr/2000/cr-xmldsig-core-20001031/signature-example-dsa.xml上記と同様ですが、DSAを使用します。
Authentication Code 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 (integrity) but not signer authentication
認証コード共有キーのアプリケーションから生成された値は、メッセージ認証（整合性）のプロパティを持つが、署名者認証のプロパティを備えているように、暗号化アルゴリズムを介してメッセージへのメッセージへ
Authentication, Message "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]
認証、メッセージ「署名は署名されているものを識別し、検出せずに署名された問題または署名のいずれかを偽造または変更することは実行不可能にする必要があります。」[デジタル署名ガイドライン、ABA]
Authentication, Signer "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]
認証、署名者「署名は、誰がドキュメント、メッセージ、または記録に署名したかを示す必要があり、他の人が許可なしに作成することは難しいはずです。」[デジタル署名ガイドライン、ABA]
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].
データオブジェクト（コンテンツ/ドキュメント）アプリケーションによって操作されている実際のバイナリ/オクテットデータ（変換、消化、または署名）で操作されています - 頻繁にHTTPエンティティ[HTTP]。固定名詞オブジェクトは、特定のXML要素を指定することに注意してください。時折、データオブジェクトをドキュメントまたはリソースのコンテンツとして参照します。要素コンテンツという用語は、XMLの開始タグ[XML]間のデータを記述するために使用されます。XMLドキュメントという用語は、XML仕様[XML]に準拠するデータオブジェクトを記述するために使用されます。
Integrity The inability to change a message without also changing the signature value. See message authentication.
整合性署名値を変更せずにメッセージを変更できないこと。メッセージ認証を参照してください。
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.
オブジェクト任意の（非コア）データを配置できる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 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 signer authentication and message authentication (integrity). (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 the structure of the Signature element type and its children (including SignatureValue) and mandatory to support 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.
署名、デタッチされた署名は、署名要素の外部のコンテンツを超えており、URIまたは変換を介して識別できます。したがって、署名は、署名するコンテンツから「分離」されます。この定義は通常、個別のデータオブジェクトに適用されますが、署名とデータオブジェクトが同じXMLドキュメント内に存在するが、兄弟要素であるインスタンスも含まれます。
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).
署名、署名を包むのは、署名自体のオブジェクト要素内にあるコンテンツを介しています。オブジェクト（またはそのコンテンツ）は、参照（URIフラグメント識別子または変換を介して）を介して識別されます。
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.
署名、署名は、要素として署名を含むXMLコンテンツを介しています。コンテンツは、ルートXMLドキュメント要素を提供します。明らかに、包み込まれた署名は、署名数値の計算に自分の価値を含めないように注意する必要があります。
Transform The processing of a octet stream from source content to derived content. Typical transforms include XML Canonicalization, XPath, and XSLT.
ソースコンテンツから派生コンテンツにオクテットストリームの処理を変換します。典型的な変換には、XML Canonicalization、XPath、およびXSLTが含まれます。
Validation, Core The core processing requirements of this specification requiring signature validation and SignedInfo reference validation.
検証、署名検証とSigneDINFO参照検証を必要とするこの仕様のコア処理要件をコアします。
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).
検証、署名SignatureValueは、コア検証で指定されているように、CanOnicalizationMethodおよびSignatureMethodを使用してSignedInfoを処理した結果と一致します（セクション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.
検証、信頼/アプリケーションアプリケーションは、署名に関連するセマンティクスが有効であると判断します。たとえば、アプリケーションはタイムスタンプまたは署名者キーの完全性を検証する場合がありますが、この動作はこのコア仕様の外部です。
ABA Digital Signature Guidelines. http://www.abanet.org/scitech/ec/isc/dsgfree.html
ABAデジタル署名ガイドライン。http://www.abanet.org/scitech/ec/isc/dsgfree.html
Bourret Declaring Elements and Attributes in an XML DTD. Ron Bourret. http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xmldtd.html
XML DTDの要素と属性を宣言するBourret。Ron Bourret。http://www.informatik.tu-darmstadt.de/dvs1/staff/bourret/xml/xmldtd.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-1. Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/fips/fips1861.pdf
DSS FIPS Pub 186-1。デジタル署名標準（DSS）。米国商務省/国立標準技術研究所。http://csrc.nist.gov/fips/fips1861.pdf
HMAC Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. http://www.ietf.org/rfc/rfc2104.txt
HMAC Krawczyk、H.、Bellare、M。and R. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。http：//www.ietf.org/rfc/rfc2104.txt
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://www.ietf.org/rfc/rfc2616.txt
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、1999年6月。http：//www.ietf.org/rfc/rfc2616.txt
KEYWORDS Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt
キーワードBradner、S。、「要件レベルを示すためにRFCSで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。http：//www.ietf.org/rfc/rfc2119.txt
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. http://www.ietf.org/rfc/rfc2253.txt
LDAP-DN Wahl、M.、Kille、S。and T. Howes、「Lightweight Directory Access Protocol（V3）：UTF-8文字列識別名の表現」、RFC 2253、1997年12月。http：//www.ietf。org/rfc/rfc2253.txt
MD5 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. http://www.ietf.org/rfc/rfc1321.txt
MD5 Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。http：//www.ietf.org/rfc/rfc1321.txt
MIME Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. http://www.ietf.org/rfc/rfc2045.txt
Mime Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、1996年11月。http：//www.ietf.org/rfc/rfc2045.txt
NFC TR15. Unicode Normalization Forms. M. Davis, M. Drst. Revision 18: November 1999.
NFC TR15。ユニコード正規化フォーム。M.デイビス、M。Drst。改訂18：1999年11月。
PGP Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", November 1998. http://www.ietf.org/rfc/rfc2440.txt
PGP Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「OpenPGPメッセージフォーマット」、1998年11月。http：//www.ietf.org/rfc/rfc2440.txt.txt
RANDOM Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. http://www.ietf.org/rfc/rfc1750.txt
ランダムイーストレイク、D。、クロッカー、S。、およびJ.シラー、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。http：//www.ietf.org/rfc/rfc1750.txt
RDF RDF Schema W3C Candidate Recommendation. D. Brickley, R.V. Guha. March 2000. http://www.w3.org/TR/2000/CR-rdf-schema-20000327/ RDF Model and Syntax W3C Recommendation. O. Lassila, R. Swick. February 1999. http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
RDF RDFスキーマ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. http://www.ietf.org/rfc/rfc2437.txt
PKCS1 Kaliski、B。and J. Staddon、「PKCS＃1：RSA暗号化仕様バージョン2.0」、RFC 2437、1998年10月。http：//www.ietf.org/rfc/rfc2437.txt
SAX SAX: The Simple API for XML David Megginson et. al. May 1998. http://www.megginson.com/SAX/index.html
SAX SAX：XML David Megginson ETのシンプルなAPI。アル。1998年5月。http：//www.megginson.com/sax/index.html
SHA-1 FIPS PUB 180-1. Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/fips/fip180-1.pdf
Sha-1 Fips Pub 180-1。安全なハッシュ標準。米国商務省/国立標準技術研究所。http://csrc.nist.gov/fips/fip180-1.pdf
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. http://www.ietf.org/rfc/rfc2781.txt
UTF-16 Hoffman、P。and F. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。http：//www.ietf.org/rfc/rfc2781.txtxt
UTF-8 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. http://www.ietf.org/rfc/rfc2279.txt
UTF-8 Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。http：//www.ietf.org/rfc/rfc2279.txt
URI Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. http://www.ietf.org/rfc/rfc2396.txt
Uri Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。http：//www.ietf.org/rfc/rfc2396.txt
URI-Literal Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. http://www.ietf.org/rfc/rfc2732.txt
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. http://www.ietf.org/rfc/rfc1738.txt
URL Berners-Lee、T.、Masinter、L。and M. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。http：//www.ietf.org/rfc/rfc1738.txt
URN Moats, R., "URN Syntax" RFC 2141, May 1997. http://www.ietf.org/rfc/rfc2141.txt
Urn Moats、R。、「Urn Syntax」RFC 2141、1997年5月。http：//www.ietf.org/rfc/rfc2141.txt
Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN Namespace Definition Mechanisms", RFC 2611, June 1999. http://www.ietf.org/rfc/rfc2611.txt
Daigle、L.、van Gulik、D.、Iannella、R。、およびP. Faltstrom、「urn Namepace Definition Mechanismss」、RFC 2611、1999年。http：//www.ietf.org/rfc/rfc2611.txt
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 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：拡張可能なハイパーテキストマークアップ言語の推奨。S.ペンバートン、D。ラゲット、他アル。2000年1月。http：//www.w3.org/tr/2000/rec-xhtml1-20000126/
XLink XML Linking Language. Working Draft. S. DeRose, D. Orchard, B. Trafford. July 1999. http://www.w3.org/1999/07/WD-xlink-19990726
Xlink XMLリンク言語。ワーキングドラフト。S.デロース、D。オーチャード、B。トラフォード。1999年7月。http：//www.w3.org/1999/07/wd-xlink-1990726
XML Extensible Markup Language (XML) 1.0 Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. February 1998. http://www.w3.org/TR/1998/REC-xml-19980210
XML拡張可能なマークアップ言語（XML）1.0推奨。T.ブレイ、J。パオリ、C。M。スペルバーグ-mcqueen。1998年2月。http：//www.w3.org/tr/1998/rec-xml-19980210
XML-C14N J. Boyer, "Canonical XML Version 1.0", RFC 3076, September 2000. http://www.w3.org/TR/2000/CR-xml-c14n-20001026 http://www.ietf.org/rfc/rfc3076.txt
XML-C14N J. Boyer、「Canonical XMLバージョン1.0」、RFC 3076、2000年9月。http：//www.w3.org/tr/2000/cr-xml-c14n-20001026 http://www.ietf.org/rfc/rfc3076.txt
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", July 1998. http://www.ietf.org/rfc/rfc2376.txt
XML-MT Whitehead、E。and M. Murata、「XML Media Types」、1998年7月。http：//www.ietf.org/rfc/rfc2376.txt
XML-ns Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. Janury 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-NS XML推奨の名前空間。T.ブレイ、D。ホランダー、A。レイマン。Janury 1999. http://www.w3.org/tr/1999/rec-xml-names-19990114
XML-schema XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. September 2000. http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/ XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. September 2000. http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/
XML-Schema XMLスキーマパート1：作業ドラフトを構造。D.ビーチ、M。マロニー、N。メンデルショーン。2000年9月。http：//www.w3.org/tr/2000/wd-xmlschema-1-20000922/ xmlスキーマパート2：データ型ワーキングドラフト。P.ビロン、A。マルホトラ。2000年9月。http：//www.w3.org/tr/2000/wd-xmlschema-2-20000922/
XML-Signature-RD Reagle, J., "XML Signature Requirements", RFC 2907, April 2000. http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014 http://www.ietf.org/rfc/rfc2807.txt
XML-Signature-Rd Reagle、J。、「XML Signature Recomisess」、RFC 2907、2000年4月。http：//www.w3.org/tr/1999/wd-xmldsig-requirements-19991014 http：//www.ietf.org/rfc/rfc2807.txt
XPath XML Path Language (XPath)Version 1.0. Recommendation. J. Clark, S. DeRose. October 1999. http://www.w3.org/TR/1999/REC-xpath-19991116
XPath XML PATH言語（XPATH）バージョン1.0。おすすめ。J.クラーク、S。デロース。1999年10月。http：//www.w3.org/tr/1999/rec-xpath-19991116
XPointer XML Pointer Language (XPointer). Candidate Recommendation. S. DeRose, R. Daniel, E. Maler. http://www.w3.org/TR/2000/CR-xptr-20000607
Xpointer XMLポインター言語（XPointer）。候補者の推奨。S.デロース、R。ダニエル、E。マラー。http://www.w3.org/tr/2000/cr-xptr-20000607
XSL Extensible Stylesheet Language (XSL) Working Draft. S. Adler, A. Berglund, J. Caruso, S. Deach, P. Grosso, E. Gutentag, A. Milowski, S. Parnell, J. Richman, S. Zilles. March 2000. http://www.w3.org/TR/2000/WD-xsl-20000327/xslspec.html
XSL拡張可能なStyleSheet Language（XSL）作業ドラフト。S. Adler、A。Berglund、J。Caruso、S。Deach、P。Grosso、E。Gutentag、A。Milowski、S。Parnell、J。Richman、S。Zilles。2000年3月。http：//www.w3.org/tr/2000/wd-xsl-20000327/xslspec.html
XSLT XSL Transforms (XSLT) Version 1.0. Recommendation. J. Clark. November 1999. http://www.w3.org/TR/1999/REC-xslt-19991116.html
XSLT XSL変換（XSLT）バージョン1.0。おすすめ。J.クラーク。1999年11月。http://www.w3.org/tr/1999/rec-xslt-1991116.html
Donald E. Eastlake 3rd Motorola, Mail Stop: M2-450 20 Forbes Boulevard Mansfield, MA 02048 USA
ドナルドE.イーストレイク第3モトローラ、メールストップ：M2-450 20フォーブス大通りマンスフィールド、マサチューセッツ州02048 USA
Phone: 1-508-261-5434 EMail: Donald.Eastlake@motorola.com
電話：1-508-261-5434メール：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
電話：1.617.258.7621メール：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
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。