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
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.
著作権（C）2001ザ・インターネット協会＆W3C（MIT、INRIA、慶應義塾大学）、すべての権利予約。
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（Extensible Markup Language）のデジタル署名処理ルールと構文を指定します。 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.)
読みやすさ、簡潔さ、そしてこの文書は、一般的に、すべてのtypes.Obviouslyのデジタル認証値を参照するために用語「署名」を使用して、歴史的な理由から、この用語はまた、厳密に公開鍵に基づいて認証値を参照するために使用し、その署名者を提供しています認証。特に対称秘密キーコードに基づいて認証値を議論するとき、我々は用語の認証者または認証コードを使用します。 （セキュリティモデル、セクション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スキーマ]およびDTD [XML]の両方を使用します。 （DTD構文に慣れていない読者がロン・ブーレの「宣言要素およびXML DTDの属性」[ブーレ]を参照することを望むかもしれない。）スキーマ定義は、現在規範的です。
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]:
この仕様でキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "べきではない" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC2119 [KEYWORDS]で説明されるように解釈されます。
"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名前空間仕様[XML-NS]に準拠は、以下のように記載されている "REQUIRED"。
The design philosophy and requirements of this specification are addressed in the XML-Signature Requirements document [XML-Signature-RD].
デザイン哲学とこの仕様の要件は、XML-署名要件ドキュメント[XML-署名-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#"
いかなる規定は、この構文で明示的なバージョン番号のために作られていません。将来のバージョンが必要な場合は、この（日付）仕様の実装によって使用されなければならないURIが異なる名前空間XML名前空間[XML-NS]を使用する：のxmlns = "http://www.w3.org/2000 / 09 / XMLDSIG＃」
This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML-namespaces, the use of internal entities [XML] or our "dsig" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.
この名前空間は、この仕様で使用されるアルゴリズム識別子の接頭辞として使用されています。アプリケーションは、XMLおよびXML-名前空間、内部実体[XML]または当社の「DSIG」のXML名前空間接頭辞を使用すると、デフォルト設定をサポートする必要がありますが/スコープ規則はオプションです。私たちは、コンパクトで読みやすい例を提供するために、これらの施設を使用しています。
This specification uses Uniform Resource Identifiers [URI] to identify resources, algorithms, and semantics. The URI in the namespace declaration above is also used as a prefix for URIs under the control of this specification. For resources not under the control of this specification, we use the designated Uniform Resource Names [URN] or Uniform Resource Locators [URL] defined by its normative external specification. If an external specification has not allocated itself a Uniform Resource Identifier we allocate an identifier under our own namespace. For instance:
この仕様は、リソース、アルゴリズム、およびセマンティクスを識別するために、統一リソース識別子[URI]を使用しています。上記の名前空間宣言におけるURIはまた、本明細書の制御下URIの接頭辞として使用されます。この仕様の制御下にあるリソースではないために、私たちはその規範的な外部仕様で定義された指定された統一リソース名[URN]またはユニフォームリソースロケータ[URL]を使用します。外部仕様自体が割り当てられていない場合は統一資源識別子は、我々は我々自身の名前空間の下の識別子を割り当てます。例えば：
SignatureProperties is identified and defined by this specification's namespace http://www.w3.org/2000/09/xmldsig#SignatureProperties
SignaturePropertiesが識別され、この仕様の名前空間http://www.w3.org/2000/09/xmldsig#SignaturePropertiesによって定義されます
XSLT is identified and defined by an external URI http://www.w3.org/TR/1999/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:
最後に、簡潔な名前空間宣言を提供するために、我々は時々のURI内の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> ...
<？xmlのバージョン= '1.0'？> <！DOCTYPE署名SYSTEM "XMLDSIG-コアschema.dtd" [<！ENTITYのDSIG "http://www.w3.org/2000/09/xmldsig#">]> <署名の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コーポレーション（著）*ジョン・ボワイエ、PureEdge（著）*マリアノP. Consens、ウォータールー大学
* 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日、モトローラ（椅子、著者/編集者）*バーブフォックス、マイクロソフト（著）*クリスチャンGeuer-Pollmann、大学ジーゲン*トムGindin、IBM *フィリップハラム - ベイカー、ベリサイン社*リチャードHimes、米国の裁判所*マーリン・ヒューズ、ボルチモア*グレゴールKarlinger、IAIK TUグラーツ*ブライアン・ラマキア、マイクロソフト*ピーターLIPP、IAIK TUグラーツ*ジョセフReagle、W3C（椅子、著者/編集者）*エド・サイモン、エントラストテクノロジーズ株式会社（著）*デビッド・ソロ、シティグループ（著者/編集者）* Petteri Stenius、DONE情報は、株式会社*ラガバンスリニバス、日*ケント田村、IBM * Winchelトッド・ヴィンセントIII、GSU *カール・ウォレス、Corsec Security社*グレッグ・ホワイトヘッド、Signio株式会社
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の代わりに。 *マーティン・J. Duerst、W3C。そして正浩関口、富士通、国際WG / IGの代わりに。 *ジョナサン・マーシュ、Microsoftは、拡張スタイルシート言語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デジタル署名は、以下の構造を有するSignature要素によって表される（「？」;「+」は、一つ以上の発生を示し、ゼロまたは1つの発生を表す「*」は0回以上の繰り返しを表します）：
<Signature> <SignedInfo> (CanonicalizationMethod) (SignatureMethod) (<Reference (URI=)? > (Transforms)? (DigestMethod) (DigestValue) </Reference>)+ </SignedInfo> (SignatureValue) (KeyInfo)? (Object)* </Signature>
<署名> <たSignedInfo>（CanonicalizationMethodに）（のSignatureMethod）（<参照（URI =）？>（トランスフォーム）？（DigestMethod）（DigestValue）</参照>）+ </たSignedInfo>（SignatureValue）（のKeyInfo）？ （オブジェクト）* </署名>
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].
署名は、URIを[URI]を介してデータオブジェクトに関連しています。 XML文書内で、署名はフラグメント識別子を介してローカルデータオブジェクトに関連しています。そのようなローカルデータを包囲署名内に含まれ得るか、またはエンベロープ署名を囲むことができます。分離署名は、外部のネットワークリソースまたは兄弟要素と同じXML文書内に存在するローカルデータオブジェクトを超えています。この場合には、署名はどちらも包み込む（署名が親である）にも包まれ（署名が子供である）です。 Signature要素（とそのID属性値/名）、又は単一のXMLドキュメント内の他の要素（とそのID）と組み合わせることが-が共存可能性があるので、注意が違反後続衝突が存在しないように、名前を選択する際に注意しなければなりませんID一意性妥当性制約[XML]。
The following example is a detached signature of the content of the HTML4 in XML specification.
次の例では、XML仕様のHTML4のコンテンツの分離署名です。
[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/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"/>
[S01] <署名ID = "MyFirstSignature" のxmlns = "http://www.w3.org/2000/09/xmldsig#"> [S02] <たSignedInfo> [S03] <CanonicalizationMethodにアルゴリズム= "HTTP：// WWW .w3.org / TR / 2000 / CR-XML-C14N-20001026 "/> [S04] <のSignatureMethodアルゴリズム=" http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> [ S05] <参考URI = "http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [S06] <トランスフォーム> [S07] <アルゴリズムを変革= "の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>
[S08] </トランスフォーム> [S09] <DigestMethodアルゴリズム= "http://www.w3.org/2000/09/ XMLDSIG＃SHA1" /> [S10] <DigestValue> j6lwx3rvEPO0vKtMup4NbeVu8nk = </ DigestValue> [S11] </リファレンス> [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] </署名>
[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上の署名の検証やたSignedInfo内の各リファレンスダイジェストの検証：たSignedInfoのコア検証は、2つの必須のプロセスで構成されています。 SignatureValue要素がたSignedInfoの外側にある間SignatureValueを計算する際に使用されるアルゴリズムはまた、署名された情報に含まれていることに留意されたいです。
[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はSignatureValueに正規化されたSignedInfoを変換するために使用されるアルゴリズムです。それは、例えば、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各Reference要素は、ダイジェスト方法を含むと識別されたデータオブジェクトにわたって計算値ダイジェスト得られます。また、ダイジェスト操作への入力を生成変換を含むことができます。データオブジェクトは、そのダイジェスト値とその値を超える署名を計算することによって署名されます。署名は、後で参照すると、署名の検証を介してチェックされます。
[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>
// WWW：[S05] <参考URI = "http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [S06] <トランスフォーム> [S07] <アルゴリズム= "HTTPを変換します。 w3.org/TR/2000/ CR-XML-C14N-20001026 "/> [S08] </トランスフォーム> [S09] <DigestMethodアルゴリズム=" http://www.w3.org/2000/09/ XMLDSIG＃SHA1 「/> [S10] <DigestValue> j6lwx3rvEPO0vKtMup4NbeVu8nk = </ DigestValue> [S11] </参照>
[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この識別は、変換と一緒に、彼らはそれを消化した形態（すなわち、消化されたコンテンツ）で署名されたデータオブジェクトを取得する方法で署名者によって提供される説明です。検証者は限りダイジェストを検証するように別の方法で消化されたコンテンツを取得してもよいです。特に、検証者は、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]トランスフォームは、それが消化される前に、リソースのコンテンツに適用された処理ステップのオプションの順序付きリストです。変換は、正規化、（圧縮/膨張を含む）符号化/復号化、XSLTおよびXPathなどの操作を含むことができます。 XPathは、ソースドキュメントの部分を省略した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を得るために適用された後にデータに適用されるアルゴリズムです。 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]など、他の技術、に依存している必要があります。 Signature要素を参照するために、独自のマークアップ内assuredby属性：たとえば、アプリケーションはFOOを使用する場合があります。したがって、それは理解し、署名の有効性とassuredby構文の意味を与えられた信頼の意思決定を行う方法を知っていなければならないアプリケーションです。我々はまた、署名自体に関するアサーションを含めるためSignatureProperties要素タイプを定義する（例えば、署名セマンティクス、署名の時間または暗号化プロセスで使用されるハードウェアのシリアル番号）。そのようなアサーションはたSignedInfoにSignaturePropertiesの参照を含むことによって署名することができます。署名アプリケーションは、それが（それがSignaturePropertyであるかを理解すべきである）に署名かについては非常に注意する必要がありますが、受信側のアプリケーションは、（その親の信頼エンジンがすることを望むかもしれないが）意味的なことを理解する義務を負いません。署名生成に関するコンテンツはSignatureProperty要素内に配置することができます。必須ターゲット属性は、プロパティが適用されるSignature要素を参照します。
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>
[] <署名ID = "MySecondSignature" ...> [P01] <たSignedInfo>] ... [P02] <参考URI = "http://www.w3.org/TR/xml-stylesheet/"> [] ... [P03] <参考URI = "＃AMadeUpTimeStamp" [P04]タイプ= "http://www.w3.org/2000/09/ XMLDSIG＃SignatureProperties"> [P05] <DigestMethodアルゴリズム= "HTTP ：//www.w3.org/2000/09/ XMLDSIG＃1 SHA1" /> [P06] <DigestValue> k3453rvEPO0vKtMup4NbeVu8nk = </ DigestValue> [P07] </参照>
[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>
[P08] </たSignedInfo> [P09] ... [P10] <オブジェクト> [P11] <SignatureProperties> [P12] <SignatureProperty ID = "AMadeUpTimeStamp" TARGET = "＃1 MySecondSignature"> [P13] <タイムスタンプのxmlns =」 http://www.ietf.org/rfc3075.txt "> [P14] <日付> 19990908 </日付> [P15] <時間> 14：34：34：34 </時間> [P16] </タイムスタンプ> [P17] </ SignatureProperty> [P18] </ SignatureProperties> [P19] </ OBJECT> [P20] </署名>
[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]参照のオプションType属性は、URIで識別されるリソースに関する情報を提供します。特に、それは、オブジェクト、SignatureProperty、またはマニフェスト要素であることを示すことができます。これは、いくつかの参考要素の特別な処理を開始するためにアプリケーションで使用することができます。 Object要素内の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.
マニフェスト要素は、直接この仕様の必須の部分で扱われていない追加的な要件を満たすために提供されます。二つの要件と方法マニフェストは、彼らが次の満足しています。
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内のすべての参照を必要とするためただし、一部のアプリケーションでは、このアプローチに関連したコア検証動作を望まないかもしれない - DigestValue要素がチェックされます。これらのアプリケーションは、自分自身への参照を検証意思決定ロジックを確保することを望むかもしれません。例えば、アプリケーションは、3つの基準要素を含む署名有効SignedInfoエレメントを受け取るかもしれません。単一の参照が失敗した場合（識別されたデータオブジェクト消化時に指定DigestValueを生じない）署名がコア検証に失敗します。ただし、アプリケーションが有効なように、2つの有効な参考要素の上に署名を治療またはその失敗に応じて、異なるアクションを実行することもできます。これを達成するために、たSignedInfoは（たSignedInfoと同じ構造を有する）1つまたは複数の基準要素を含むマニフェスト要素を参照することになります。次に、マニフェストの基準の検証は、アプリケーションの制御下にあります。
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.
以下の例では、Object要素内に見出さマニフェストに署名の言及を含みます。
[ ] ... [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>
[] ... [M01] <参考URI = "＃1 MyFirstManifest" [M02]タイプ= "http://www.w3.org/2000/09/xmldsig#Manifest"> [M03] <DigestMethodアルゴリズム= "HTTP ：//www.w3.org/2000/09/ XMLDSIG番号のSHA1" /> [M04] <DigestValue> 345x3rvEPO0vKtMup4NbeVu8nk = </ DigestValue> [M05] </参考> [] ... [M06] <オブジェクト> [ M07] <マニフェストID = "MyFirstManifest"> [M08] <参考> [M09] ... [M10] </参考> [M11] <参考> [M12] ... [M13] </参考> [M14 ] </マニフェスト> [M15] </ OBJECT>
The sections below describe the operations to be performed as part of signature generation and validation.
以下のセクションでは、署名生成および検証の一部として実行される動作を記述する。
The REQUIRED steps include the generation of Reference elements and the SignatureValue over SignedInfo.
必要な手順は、Reference要素とのSignedInfo以上SignatureValueの世代が含まれます。
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.
前記データオブジェクトの（任意）の識別、任意（オプション）要素、ダイジェストアルゴリズムとDigestValue変換を含む、Reference要素を作成します。
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におよびリファレンス（S）とのSignedInfoエレメントを作成します。 2.正規化した後たSignedInfoで指定されたアルゴリズムに基づいたSignedInfo上SignatureValueを計算します。 3.たSignedInfoを含むSignature要素を構築し、オブジェクト（複数可）（所望であれば、符号化は、署名に使用されるものとは異なっていてもよい）、の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内の各リファレンスに含まれるダイジェストの検証、及びたSignedInfoにわたって計算されたシグニチャの（2）暗号署名検証を含みます。
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）に依存し、Reference要素に署名者によって提供されるトランスフォーム、またはそのようなローカル・キャッシュのような他の手段を介してコンテンツを得てもよい。）3.ダイジェストは、指定されたDigestMethodを使用して得られたデータオブジェクトそのリファレンス仕様インチ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エレメント上SignatureValueを検証します。
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.
また、URIのSignatureMethodはたSignedInfoの正規化（相対URIの例えば、absolutization）によって変更された可能性があり、それが使用されなければならない標準形です。しかし、この仕様書の必要な標準化[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:
XML署名の一般的な構造は、署名の概要（セクション2）に記載されています。このセクションでは、コア署名機能の詳細な構文を提供します。特に明記しない限り、このセクションで説明する機能を実装するために必須です。構文は、以下のXMLプリアンブル、宣言、内部エンティティ、及び単純でDTDおよび[XML-スキーマ]を介して定義されます。
Schema Definition:
スキーマ定義：
<!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#'> ]>
<！DOCTYPEスキーマPUBLIC " - // W3C // DTD XMLSCHEMA 200010 // EN" "http://www.w3.org/2000/10/XMLSchema.dtd" [<ATTLISTスキーマの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">
<スキーマのxmlns = "http://www.w3.org/2000/10/XMLSchema" のxmlns：DS = "＆DSIG;" targetNamespace = "＆DSIG;"バージョン= "0.1" のelementFormDefault = "資格">
<!-- Basic Types Defined for Signatures -->
<！ - 署名のために定義された基本的なタイプ - >
<simpleType name="CryptoBinary"> <restriction base="binary"> <encoding value="base64"/> </restriction> </simpleType> DTD:
<単純名= "CryptoBinary"> <制限基地= "バイナリ"> <符号化値= "BASE64" /> </制限> </ 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)*'>
<！ENTITY％のObject.ANY '（#PCDATA |署名| SignatureProperties |マニフェスト）*'> <！ENTITY％のMethod.ANY '（#PCDATAは| HMACOutputLength）*'> <！ENTITY％以下のTransform.ANY「（#PCDATA | XPathの| XSLT） '> <！ENTITY％以下のSignatureProperty.ANY '（#PCDATA）*'> <ENTITY％のKey.ANY！'（#PCDATA |キー名|です。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:
Signature要素は、XML署名のルート要素です。署名要素は、次のスキーマ定義に対するlaxlyスキーマ妥当[XMLスキーマ]でなければなりません：スキーマ定義：
<element name="Signature"> <complexType> <sequence> <element ref="ds:SignedInfo"/>
<要素名= "署名"> <complexTypeの> <シーケンス> <要素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：オブジェクト" のminOccurs = "0" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの> </要素> DTD：
<!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*) > <!ATTLIST Signature xmlns CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#' Id ID #IMPLIED >
<！ELEMENT署名（たSignedInfo、SignatureValue、KeyInfoの？、オブジェクト*）> <！ATTLIST署名のxmlns CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#' イド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:
<要素名= "SignatureValue" タイプ= "DS：CryptoBinary" /> DTD：
<!ELEMENT SignatureValue (#PCDATA) >
<！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の構造は、正規化アルゴリズム、署名アルゴリズム、および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は、明示的な署名を含むか、または（例えば、計算時間、暗号デバイスシリアルナンバー、等）の特性を消化しません。アプリケーションが署名付きプロパティを関連付けるまたは消化する必要がある場合、そのオブジェクト要素内SignatureProperties要素にそのような情報を含むことができます。スキーマ定義：
<element name="SignedInfo"> <complexType> <sequence> <element ref="ds:CanonicalizationMethod"/> <element ref="ds:SignatureMethod"/> <element ref="ds:Reference" maxOccurs="unbounded"/> </sequence>
<要素名= "たSignedInfo"> <complexTypeの> <シーケンス> <要素REF = "DS：CanonicalizationMethodに" /> <要素REF = "DS：のSignatureMethod" /> <要素REF = "DS：リファレンス" のmaxOccurs = "無制限" /> </シーケンス>
<attribute name="Id" type="ID" use="optional"/> </complexType> </element> DTD:
<名前= "ID" タイプ= "ID" を使用する属性= "オプション" /> </ complexTypeの> </要素> DTD：
<!ELEMENT SignedInfo (CanonicalizationMethod, SignatureMethod, Reference+) > <!ATTLIST SignedInfo Id ID #IMPLIED>
<！ELEMENTたSignedInfo（CanonicalizationMethodに、のSignatureMethod、リファレンス+）> <！ATTLISTたSignedInfoイド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）に記載のアルゴリズムの一般的な構造を使用します。実装はREQUIRED Canonicalの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）とカノニカルXMLおよび最小正規化（セクション6.5.1で指定されたCRLFとcharset正規化）として必要カノニカルXMLアルゴリズム（セクション6.5.2）に代わるものは、明示的に指定しなくていることができます必須。したがって、その使用にはサポート指定されたアルゴリズムを（セクション7、XML正規化と構文制約の考慮事項を参照）を実行しない他のアプリケーションと相互運用しない場合があります。非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).
*実装は、XPathの元々たSignedInfoを含む、現在たSignedInfoを示す文書から形成されたノードセット、子孫、そしてたSignedInfoの属性と名前空間ノードを備えていなければならないカノニカルXML [XML-C14N]（またはコメントなし）とその子孫要素（名前空間コンテキストとの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を生成するために実装するCanonicalのXML [XML-C14N]のアルゴリズムを実装し、代わりに、最小限の正規化（またはいくつかの他の形式）を選択しないリソースに制約のあるアプリケーションをする人とセキュリティ上の懸念。 （結果は、元の正規の形式ではないかもしれないが、それはまだ標準形であることができる。）例えば、そのような実装では、（少なくとも）[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:
<要素名= "CanonicalizationMethodに"> <complexTypeの> <シーケンス> <任意の名前空間= "##あらゆる" のminOccurs = "0" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "アルゴリズム" タイプ= "URIReferenceの必要な "/> </ complexTypeの> </要素> DTD "=を使用します"：
<!ELEMENT CanonicalizationMethod %Method.ANY; > <!ATTLIST CanonicalizationMethod Algorithm CDATA #REQUIRED >
<！ELEMENT CanonicalizationMethodに％のMethod.ANY。 > <！ATTLIST CanonicalizationMethodにアルゴリズム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>
<要素名= "のSignatureMethod"> <complexTypeの> <シーケンス> <任意の名前空間= "##あらゆる" のminOccurs = "0" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "アルゴリズム" タイプ= "URIReferenceの"使用=" 必須 "/> </ complexTypeの>
</element> DTD:
</要素> DTD：
<!ELEMENT SignatureMethod %Method.ANY; > <!ATTLIST SignatureMethod Algorithm CDATA #REQUIRED >
<！ELEMENTのSignatureMethod％のMethod.ANY。 > <！ATTLISTのSignatureMethodアルゴリズム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）と変換消化コンテンツ（ダイジェスト方法に、すなわち、入力）が作成された方法について説明します。 Type属性は、参照されたデータの処理を容易にします。この仕様は、外部データに対して何ら要求をしないながら、例えば、アプリケーションは、リファレントがマニフェストであることを知らせることを望むことができます。オプションの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:
<要素名= "参考"> <complexTypeの> <シーケンス> <要素REF = "DS：トランスフォーム" のminOccurs = "0" /> <要素REF = "DS：DigestMethod" /> <要素REF = "DS：DigestValue" /> </シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> <属性名= "URI" タイプ= "URIReferenceの" 使用= "オプション" /> <属性名= "タイプ"TYPE =" URIReferenceの」使用= "オプション" /> </ complexTypeの> </要素> DTD。
<!ELEMENT Reference (Transforms?, DigestMethod, DigestValue) > <!ATTLIST Reference Id ID #IMPLIED URI CDATA #IMPLIED Type CDATA #IMPLIED >
<！ELEMENTリファレンス（トランスフォーム?, DigestMethod、DigestValue）> <！ATTLIST参照ID ID #IMPLIED URI CDATA #IMPLIEDタイプ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:
RFC2396 [URI]で指定されたURI属性は、URI参照を使用してデータ・オブジェクトを識別する。 URI属性のために許可された文字の集合は、XML、つまり[UNICODE]の場合と同じです。しかし、いくつかのUnicode文字は、すべての非ASCII文字とRFC2396 [URI、セクション2.4]に記載されている除外文字を含むURI参照から禁止されています。ただし、番号記号（＃）、パーセント記号（％）、および角括弧文字RFC 2732に再許可[URI-リテラル]が許可されています。次のように許可されていない文字をエスケープする必要があります。
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はバイト値の16進表記である％HHに変換）。 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クッキー、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 /相互運用性 - プレスリリース）。 （参照処理の詳細についてはリファレンス検証（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属性が完全に省略された場合、受信側アプリケーションは、オブジェクトのアイデンティティを知ることが期待されています。例えば、軽量のデータプロトコルは、オブジェクトのアイデンティティ与えられたこの属性は、アプリケーション・コンテキストの一部である省略するかもしれません。この属性は、特定のSignedInfo、またはマニフェストで最大1つのリファレンスから省略することができます。
The optional Type attribute contains information about the type of object being signed. This is represented as a URI. For example:
オプションのtype属性は署名されるオブジェクトのタイプに関する情報が含まれています。これは、URIとして表されます。例えば：
Type="http://www.w3.org/2000/09/xmldsig#Object" Type="http://www.w3.org/2000/09/xmldsig#Manifest"
タイプ= "http://www.w3.org/2000/09/xmldsig#Object" タイプ= "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.
Type属性はで指摘されている項目に適用され、その内容ではありません。例えば、SignatureProperties要素を含むオブジェクトの要素を識別基準は、タイプ#Objectのままです。 type属性は顧問です。型情報の妥当性検査は、この仕様で必要とされません。
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]仕様に準拠する必要はありません。しかし、XPathデータモデルの定義（例えば、ノードセット）と構文は、署名生成の一部として、XML-AS-XML（代わりオクテット）を処理するもののための機能を説明するために、この文書内で使用されています。これらの機能を使用したいという方のために、準拠[XPathの]の実装では、これらの機能を実装する1つの方法ですが、それは必須ではありません。そのようなアプリケーションは、ノードセットに十分に機能的な置換を使用して、この仕様によって必要とされるのみXPath式の動作を実現することができました。しかし、簡単にするために、我々は一般的にすべての点でこの資格を含めずにXPathの用語を使用します。 「のXPath nodesets」上の要件は、ノードセット機能的等価物を含むことができます。 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またはその後の変換の結果のデータ型は、オクテットストリームまたは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.
データオブジェクトがオクテットストリームと次transformrequiresノードセットである場合*、署名アプリケーションは、オクテットを解析しようとしなければなりません。
* 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によって指定されたダイジェストアルゴリズムは、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).)
[URI、セクション4.2]で定義されるようにURIリファレンス「は同じ文書」参照でない限り、URI参照を間接参照の結果は、オクテットストリームでなければなりません。 URIは、同じ文書の参照であるか、またはtransformthatは、XMLの構文解析を必要としない限り適用される（変換（セクション4.3.3.1を参照）。）しない限り、特に、URIによって識別されるXML文書は、署名アプリケーションによって解析されていません
When a fragment is preceded by an absolute or relative URI in the URI-Reference, the meaning of the fragment is defined by the resource's MIME type. Even for XML documents, URI dereferencing (including the fragment processing) might be done for the signature application by a proxy. Therefore, reference validation might fail if fragment processing is not performed in a standard way (as defined in the following section for same-document references). Consequently, we RECOMMEND that the URI attribute not include fragment identifiers and that such processing be specified as an additional XPath Transform.
フラグメントはURIリファレンスにおける絶対的または相対URIが先行する場合、断片の意味は、リソースのMIMEタイプによって定義されます。 XML文書の、（フラグメント処理を含む）間接参照URIは、プロキシによって署名アプリケーションのために行われるかもしれません。したがって、基準の検証は（同じ文書参照の次のセクションで定義されるような）フラグメント処理は、標準的な方法で実行されていない場合に失敗する可能性があります。したがって、我々は、URIがフラグメント識別子を含み、追加のXPathが変換等の処理が指定されることはない属性ことをお勧めします。
When a fragment is not preceded by a URI in the URI-Reference, XML signature applications MUST support the null URI and barename XPointer. We RECOMMEND support for the same-document XPointers '#xpointer(/)' and '#xpointer(id("ID"))' if the application also intends to support 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署名アプリケーションはヌルURIとbarenameのXPointerをサポートしなければなりません。私たちは、同じ文書のXPointers「#xpointer（/）」と「#xpointer（ID（ 『ID』））」のサポートを勧めアプリケーションはまた、コメント付き最小正規化または正規XMLをサポートしようとする場合。 （コメント付きCanonicalはXMLでも呼び出すことができる前に、それ以外の場合はURI =「＃fooが」自動的コメントを削除します。）アプリケーションが制御を持っていない可能性があるためXPointersための他のすべてのサポートは、barenameや外部リソースの他の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」は、それはおそらく、そのファイルの拡張子指定された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」は、オクテットとして設けられ、外部XMLリソース「http://example.com/bar.xml」のID属性値「第1章」で要素を識別しますストリーム。再び、相互運用性のために、「第1章」として識別された要素は、URIフラグメントよりのXPath transformratherを用いて得られるはずである（外部リソースにbarename XPointerの分解能は、本明細書では必要とされません）。
URI="" Identifies the nodeset (minus any comment nodes) of the XML resource containing the signature
署名を含むXMLリソースのURI =「」ノードセット（マイナス任意のコメント・ノード）を識別
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 =「＃1第1章は、」署名を含むXMLリソースのID属性値「第1章」を持つ要素を含むノードセットを識別する。 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:
同じ文書の参照を逆参照すると、XPathノードセットカノニカルXMLの使用に適しをもたらさなければなりません。具体的には、URI（URI =「」）NULLを逆参照するURI属性を含むXML文書のすべての非コメントノードを含むXPathノード集合をもたらさなければなりません。フラグメントURIには、番号記号（「＃」）文字の後の文字は[XPTR] XPointerの構文に準拠しています。 XPointerを処理するとき、アプリケーションは、URI属性を含むXMLドキュメントのルートノードは、XPointerの評価コンテキストを初期化するために使用されたかのように動作しなければなりません。次のようXPointerの処理の結果が得られた位置セットに由来するノードセットであるかのようにアプリケーションが振る舞うしなければなりません
1. discard point nodes 2. replace each range node with all XPath nodes having full or partial content within the range 3. replace the root node with its children (if it is in the node-set) 4. replace any element node E with E plus all descendants of E (text, comment, PI, element) and all namespace and attribute nodes of E and its descendant elements. 5. if the URI is not a full XPointer, then delete all comment nodes
1.廃棄ポイントノード2は、すべてのXPathノードが（それがノード集合内にある場合）子を有するルートノードを置き換える範囲3内に完全または部分的なコンテンツを有する各範囲のノードを置き換える4と任意の要素ノードEを置き換えますEプラス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.
カノニカルXMLノードセット子孫ノードのその非存在下でのノードの集合として扱い、一方のXPointerは、典型的には、サブツリーのルートに単に要素ノードを使用して、XML文書の構文解析ツリーのサブツリーを示しているので、最後の交換に2番目が必要です正規形からその代表的なテキストの不在下での結果。
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).
最後のステップは、ヌルのURI、barenameのXPointersと子のシーケンスXPointersのために行われます。 URIの= '＃1のXPointer（ID（ "ID"））'：識別子IDによって要素を選択してコメントを保持するために、次のフルのXPointerを使用します。文書全体を選択しながら、コメントを保持するには、以下のフルのXPointerを使用します。URIは=「＃1のXPointer（/）」。このXPointerのは、最後のステップの第二は、上記の解析ツリーのすべてのノード（すべての子孫、プラスすべての属性に加え、すべての名前空間ノード）で置き換えルートノードを含む単純なXPath式を含んでいます。
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).)
オプションのトランスフォーム要素は変換要素の順序付きリストが含まれています。これらは、署名者が消化されたデータオブジェクトを取得する方法について説明します。それぞれの出力は、次の変換の入力として機能する変換します。最初のトランスフォームへの入力は、Reference要素のURI属性を間接参照した結果です。前回からの出力変換はDigestMethodアルゴリズムの入力です。変換が適用される場合、署名者は、（元の）ドキュメントが、得られた（形質転換された）ドキュメントをネイティブに署名されていません。 （署名されたものだけを参照してください。セキュア（セクション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).)
各変換はAlgorithm属性と所定のアルゴリズムに適したコンテンツパラメータ、もしあれば、から成ります。 Algorithm属性値は、アルゴリズムの名前を実行することを指定し、変換内容は、入力変換のアルゴリズムの処理を管理するために追加のデータを提供します。 （アルゴリズムの識別子と実装要件（セクション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タイプ、文字セット（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]、正規[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>
<要素名= "トランスフォーム"> <complexTypeの> <シーケンス> <要素REF = "DS：変換" のmaxOccurs = "無制限" /> </配列> </ complexTypeの> </要素>
<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:
<要素名= "トランスフォーム"> <complexTypeの> <選択のmaxOccurs = "無制限"> <任意の名前空間= "##他" のprocessContents = "緩い" のminOccursは= "0" のmaxOccurs = "無制限" /> <要素名=」 XSLT」タイプ= "文字列" /> < - XSLする必要があります：！ - > <要素名=スタイルシート要素 "= XPathの" タイプ= "文字列" /> </選択> <属性名= "アルゴリズム" タイプ"URIReferenceの" 使用= "必須" /> </ complexTypeの> </要素> DTD。
<!ELEMENT Transforms (Transform+)>
<！ELEMENT変換（+トランスフォーム）>
<!ELEMENT Transform %Transform.ANY; > <!ATTLIST Transform Algorithm CDATA #REQUIRED >
<！ELEMENT％のTransform.ANYを変換します。 > <！ATTLIST変換アルゴリズムCDATA #REQUIRED>
<!ELEMENT XPath (#PCDATA) > <!ELEMENT XSLT (#PCDATA) >
<！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の間接参照と変換の適用の結果は、オクテットストリームである場合、変換は（コメント付き最小正規化又は正規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:
<要素名= "DigestMethod"> <complexTypeの> <シーケンス> <任意の名前空間= "##あらゆる" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "アルゴリズム"TYPE =" URIReferenceの」使用= "必須" /> </ complexTypeの> </要素> DTD。
<!ELEMENT DigestMethod %Method.ANY; > <!ATTLIST DigestMethod Algorithm CDATA #REQUIRED >
<！ELEMENT DigestMethod％のMethod.ANY。 > <！ATTLIST DigestMethodアルゴリズム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ダイジェストのエンコードされた値を含む要素です。ダイジェストは常にBASE64 [MIME]を使用して符号化されます。スキーマ定義：
<element name="DigestValue" type="ds:CryptoBinary"/> DTD:
<要素名= "DigestValue" タイプ= "DS：CryptoBinary" /> DTD：
<!ELEMENT DigestValue (#PCDATA) > <!-- base64 encoded digest value -->
<！ELEMENT DigestValue（#PCDATA）> <！ - BASE64は、ダイジェスト値をエンコード - >
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名前空間施設[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内の複数の宣言が同じキーを参照してください。アプリケーションが別の名前空間からの要素を含めることによって、彼らが選択した任意のメカニズムを定義して使用することができるが、コンプライアントバージョンはです。KeyValue（セクション4.4.2）を実装しなければならないとRetrievalMethod（セクション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.
次のリストは、この仕様で定義されたキー情報の種類をまとめたものです。これらは、オクテットストリームとして表されるように、リモートキー情報の構造を記述するためにRetrievalMethodのType属性内で使用することができます。
* 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証明書を示すために一つの追加のタイプを指定します
* 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:
<要素名は= "のKeyInfo"> <complexTypeの> <選択肢のmaxOccurs = "無制限"> <どんなのprocessContents = "緩い" 名前空間= "##他" のminOccurs = "0" のmaxOccurs = "無制限" /> <要素名=」キー名 "タイプ= "文字列"/> <要素REF = "DS：です。KeyValue"/> <要素REF = "DS：RetrievalMethod"/> <要素REF = "DS：X509Data"/> <要素REF =" DS：PGPData "/> <要素REF =" DS：SPKIData "/> <要素名=" MgmtData」タイプ= "文字列" /> </選択> <属性名= "ID" タイプ= "ID" 使用= "" オプション/ > </ complexTypeの> </要素> DTD：
<!ELEMENT KeyInfo %Key.ANY; > <!ATTLIST KeyInfo Id ID #IMPLIED >
<！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.)
KEYNAME要素は、受信者にキー識別子を通信するために署名者が使用することができる文字列値を含みます。典型的には、キー名は、メッセージに署名するために使用される鍵ペアに関連する識別子を含むが、それは間接的に鍵のペアを特定する他のプロトコルに関連する情報を含むことができます。 （キー名の一般的な用途は、キーの単純な文字列名などのキーインデックス、識別名（DN）、電子メールアドレスが含まれます）
Schema Definition:
スキーマ定義：
<!-- type declared in KeyInfo --> DTD:
<！ - KeyInfoの中で宣言された型 - > DTD：
<!ELEMENT KeyName (#PCDATA) >
<！ELEMENTキー名（#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（REQUIRED）と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>
<要素名= "です。KeyValue"> <complexTypeの混合= "真の"> <選択> <任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> <要素REF =」 DS：DSAKeyValue "/> <要素REF =" DS：RSAKeyValue "/> </選択> </ complexTypeの> </要素>
DTD: <!ELEMENT KeyValue %Key.ANY; >
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内RetrievalMethod要素が別の場所に格納されているキー情報の情報への参照を伝えるために使用されます。例えば、文書内のいくつかの署名は、文書内のまたはリモートの文書外回出現するX.509v3証明書チェーンによって検証鍵を使用するかもしれません。各署名者のKeyInfoは、X509Certificateの要素の配列を有するチェーン全体を含む単一RetrievalMethod素子を用いた代わりにこのチェーンを参照することができます。
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,
RetrievalMethodは、そこにはDigestMethodまたはDigestValue子要素ではないとURIの存在が必須であること以外は、参考のURI（セクション4.3.3.1）およびリファレンス処理モデルと同じ構文とデリファレンス動作（セクション4.3.3.2）を使用しています。間接参照し、指定されたURIを変換した結果がノードセットである場合、それは正規化されるようにする必要があるかもしれない、注意してください。本明細書（セクション4.4）によって定義されたキー情報タイプのすべては、オクテットを表します
consequently the Signature application is expected to attempt to canonicalize the nodeset via the The Reference Processing Model (section 4.3.3.2)
従って署名アプリケーションは、ザ・リファレンス処理モデル（セクション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
<要素名= "RetrievalMethod"> <complexTypeの> <シーケンス> <要素REF = "DS：トランスフォーム" のminOccurs = "0" /> </シーケンス> <属性名= "URI" タイプ= "URIReferenceの" /> <属性名前= "タイプ" タイプ= "URIReferenceの" 使用= "オプション" /> </ complexTypeの> </要素> DTD
<!ELEMENT RetrievalMethod (Transforms?) > <!ATTLIST RetrievalMethod URI CDATA #REQUIRED Type CDATA #IMPLIED >
<！ELEMENT RetrievalMethod（トランスフォーム？）> <！ATTLIST RetrievalMethod URI CDATA #REQUIREDタイプ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」（これは、参照先の種類を識別するためにRetrievalMethodまたは参照要素内で使用することができます）
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つの以上の識別子が含まれています。 X509Dataの5種類が定義されています
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サブジェクト識別名が含まれているRFC2253 [LDAP-DN]、2 X509SubjectName要素、に準拠するべきであるX.509の発行者識別名/シリアル番号のペアが含まX509IssuerSerial要素、 X.509サブジェクトキー識別子値を含むRFC2253 [LDAP-DN]、3 X509SKI要素、を有します。 4. base64でエンコードされた証明書失効リスト（CRL）[書X509v3]が含まbase64エンコード[書X509v3]証明書、および5 X509CRL要素が含まのX509Certificate要素。
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要素内にグループ化されなければなりません。 （その1つのキーに関連する）同じキーが、異なる証明書に関する複数の宣言は、単一のKeyInfo要素内でグループ化されなければならないが、複数X509Data要素で起こり得ます。例えば、次のブロックは、証明書A（発行者/シリアル番号およびSKI）と証明書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>
<のKeyInfo> <X509Data> <！ - 証明書Aには2つのポインタ - > <X509IssuerSerial> <X509IssuerName> CN =田村ケント、OU = TRL、O = IBM、L =大和市、ST =神奈川、C = JP </ X509IssuerName> <X509SerialNumber> 12345678 </ X509SerialNumber> </ X509IssuerSerial> <X509SKI> 31d97bd7 </ X509SKI> </ X509Data> <X509Data> <！ - 単一のポインタ証明書Bの - >の<X509SubjectName>件名証明書B </ X509SubjectName> </ X509Data> <！ - 証明書チェーン - > <！ - 署名者の証明書、発行者CN = arbolCA、OU = FVT、O = IBM、C = US、シリアル4 - > <X509Certificateに> MIICXTCCA .. </ X509Certificateに> <！ - 中間証明書の件名CN = arbolCA、OU = FVTO = IBM、C = USの発行者、CN = tootiseCA、OU = FVT、O =ブリッジポイント、C = US - > <X509Certificateに> MIICPzCCA ... </のX509Certificate> <！ - ルート証明書の件名CN = tootiseCA、OU = FVT、O =ブリッジポイント、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には直接の規定はありません、注意してください。しかし、証明書のセットまたはCRLがするKeyInfoで起こり得るX509Data要素と複数X509Data要素内で発生することができます。複数の証明書はX509Data要素で発生するたびに、少なくとも一つのそのような証明書は、署名を検証する公開鍵を含んでいなければなりません。スキーマ定義
<element name="X509Data"> <complexType> <choice> <sequence maxOccurs="unbounded"> <choice> <element ref="ds:X509IssuerSerial"/> <element name="X509SKI" type="ds:CryptoBinary"/> <element name="X509SubjectName" type="string"/>
<要素名= "X509Data"> <complexTypeの> <選択> <シーケンスのmaxOccurs = "無制限"> <選択> <要素REF = "DS：X509IssuerSerial" /> <要素名= "X509SKI" タイプ= "DSを：CryptoBinary" /> <要素名= "X509SubjectName" タイプ= "文字列" />
<element name="X509Certificate" type="ds:CryptoBinary"/> </choice> </sequence> <element name="X509CRL" type="ds:CryptoBinary"/> </choice> </complexType> </element>
<要素名= "X509Certificateの" タイプ= "DS：CryptoBinary" /> </選択> </シーケンス> <要素名= "X509CRL" タイプ= "DS：CryptoBinary" /> </選択> </ complexTypeの> </要素>
<element name="X509IssuerSerial"> <complexType> <sequence> <element name="X509IssuerName" type="string"/> <element name="X509SerialNumber" type="integer"/> </sequence> </complexType> </element>
<要素名= "X509IssuerSerial"> <complexTypeの> <シーケンス> <要素名= "X509IssuerName" タイプ= "文字列" /> <要素名= "X509SerialNumber" タイプ= "整数" /> </配列> </ complexTypeの> </要素>
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) >
<！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」（これは、参照先の種類を識別するためにRetrievalMethodまたは参照要素内で使用することができます）
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公開鍵識別子を含む文字列です。 [PGP、セクション5.5]で定義されるようPGPKeyPacketはbase64で符号化された鍵素材パケットを含んでいます。 PGPData要素の他のサブタイプは、OpenPGPのワーキンググループによって定義されてもよいです。スキーマ定義：
<element name="PGPData"> <complexType> <choice>
<要素名= "PGPData"> <complexTypeの> <選択>
<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>
<任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> <シーケンス> <要素名= "PGPKeyID" タイプ= "文字列" /> <要素名= "PGPKeyPacket"タイプ= "DS：CryptoBinary" /> </シーケンス> </選択> </ complexTypeの> </要素>
DTD:
DTD：
<!ELEMENT PGPData (PGPKeyID, PGPKeyPacket) > <!ELEMENT PGPKeyPacket (#PCDATA) > <!ELEMENT PGPKeyID (#PCDATA) >
<！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」（これは、参照先の種類を識別するためにRetrievalMethodまたは参照要素内で使用することができます）
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:
<要素名= "SPKIData" タイプ= "文字列" /> DTD：
<!ELEMENT SPKIData (#PCDATA) >
<！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」（これは、参照先の種類を識別するためにRetrievalMethodまたは参照要素内で使用することができます）
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)>
<！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」（これは、参照先の種類を識別するために、Reference要素内で使用することができます）
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回以上発生し得る任意の要素です。存在する場合、この要素は、任意のデータが含まれていてもよいです。 Object要素は、オプションの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.
MIMEタイプの属性は、オブジェクト内のデータを説明するオプションの属性です。これは、[MIME]で定義された値を文字列です。オブジェクトは、XMLが含まれている場合たとえば、MIMEタイプがtext / xmlである可能性があります。この属性は純粋に助言です。 MIMEタイプの情報の妥当性検査は、この仕様で必要とされません。
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、またはマニフェスト内の参照から参照されます。この要素は、典型的に署名されるオブジェクトは署名要素に含まれるべきであるシグネチャを包むために使用されます。ダイジェストは、開始タグと終了タグを含む全体のObject要素の上に計算されます。
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文書のための簡単な）実際のデータオブジェクトを識別またはA変換する必要があり、ダイジェスト計算から<オブジェクト>タグは、オブジェクトタグを削除するために使用されなければならない除外したい場合（おそらく、データ・オブジェクトが非-XML）。オブジェクトタグの排除は、1つのデータオブジェクトが署名（またはその逆）の外側に署名内部から移動された場合、署名は有効なまましたい場合のために所望され得る、またはオブジェクトの内容は符号化です元のバイナリ文書と元のビット単位の表現を署名するように抽出してデコードすることが望まれています。スキーマ定義：
<element name="Object"> <complexType mixed="true"> <sequence maxOccurs="unbounded"> <any namespace="##any" processContents="lax"/>
<要素名= "オブジェクト"> <complexTypeの混合= "真の"> <シーケンスのmaxOccurs = "無制限"> <任意の名前空間= "##あらゆる" のprocessContents = "緩いです" />
</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:
</シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> <属性名= "MIMEタイプ" タイプ= "文字列" 使用= "オプション" /> <！ - grepのファセットを追加 - > <属性名= "エンコード" タイプ= "URIReferenceの" 使用= "オプション" /> </ complexTypeの> </要素> DTD：
<!ELEMENT Object %Object.ANY; > <!ATTLIST Object Id ID #IMPLIED MimeType CDATA #IMPLIED Encoding CDATA #IMPLIED >
<！ELEMENTオブジェクト％Object.ANY。 > <！ATTLISTのオブジェクトID ID #IMPLIED MIMEタイプCDATA #IMPLIEDエンコーディング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.
このセクションでは、マニフェストとSignatureProperties要素を実装するために、オプションを説明し、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」（これは、参照先の種類を識別するために、Reference要素内で使用することができます）
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内のリストとの違いは、オブジェクトが失敗した比較アクセスできないまたはダイジェストであれば、実際に参照しているオブジェクトと何をすべきかと照合されているダイジェストの、もしあれば、アプリケーション定義されていることです。マニフェストのSignedInfoから指されている場合は、マニフェスト自体を超えるダイジェストは、コア、署名の検証動作によってチェックされます。そのようなマニフェスト内のダイジェストは、アプリケーションの裁量でチェックされます。マニフェストは、別のマニフェストから参照されている場合は、この2つのレベルの深マニフェストのも、全体のダイジェストがチェックされない場合があります。スキーマ定義：
<element name="Manifest"> <complexType> <sequence> <element ref="ds:Reference" maxOccurs="unbounded"/>
<要素名= "マニフェスト"> <complexTypeの> <シーケンス> <要素REF = "DS：リファレンス" のmaxOccurs = "無制限" />
</sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> </element> DTD:
</シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの> </要素> DTD：
<!ELEMENT Manifest (Reference+) > <!ATTLIST Manifest Id ID #IMPLIED >
<！ELEMENTマニフェスト（参考+）> <！ATTLISTマニフェストイド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」（これは、参照先の種類を識別するために、Reference要素内で使用することができます）
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:
署名（S）の生成に関する追加情報項目はSignatureProperty要素（即ち、日付/タイムスタンプまたは署名の生成に使用される暗号化ハードウェアのシリアル番号）内に配置することができます。スキーマ定義：
<element name="SignatureProperties"> <complexType> <sequence> <element ref="ds:SignatureProperty" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> </element>
<要素名= "SignatureProperties"> <complexTypeの> <シーケンス> <要素REF = "DS：SignatureProperty" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション「/> </ complexTypeの> </要素>
<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:
<要素名= "SignatureProperty"> <complexTypeの混合= "真の"> <選択肢のminOccurs = "0" のmaxOccurs = "無制限"> <任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </選択> <属性名= "ターゲット" タイプ= "URIReferenceの" 使用= "必要" /> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの> </要素> DTD：
<!ELEMENT SignatureProperties (SignatureProperty+) > <!ATTLIST SignatureProperties Id ID #IMPLIED >
<！ELEMENT SignatureProperties（SignatureProperty +）> <！ATTLIST SignaturePropertiesイドID #IMPLIED>
<!ELEMENT SignatureProperty %SignatureProperty.ANY > <!ATTLIST SignatureProperty Target CDATA #REQUIRED Id ID #IMPLIED >
<！ELEMENT SignatureProperty％SignatureProperty.ANY> <！ATTLIST SignaturePropertyのターゲットCDATA #REQUIREDイド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.
PIはCanonicalizationMethodにアルゴリズムがそれらを破棄しない限り、署名されるアプリケーションによりたSignedInfoの内部に配置されていることに注意してください。 （これは、任意の署名された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-C14N]はない）、彼らが署名される任意の他の参照されるXML内のコメントを削除しない限りことに留意されたいです。それらが保持されている場合はその結果、コメントへの変更は、署名の故障の原因となります。コメント-無視正規化/ようなカノニカルXML [XML-C14N]、指定されたような方法を、変換しない限り、同様に、任意のXMLデータに対するXML署名が変更コメントに敏感であろう。
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、変換、のSignatureMethod、またはCanonicalizationMethodに）を識別する要素の属性として表示されたURIによって識別されます。本明細書中で使用されるすべてのアルゴリズムは、パラメータを取るが、多くの場合、パラメータは暗黙的です。キーイング情報とCanonicalizationMethodに出力：たとえば、のSignatureMethodは暗黙のうちに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").)
（これらは時にはXMLシンタックス（例えば、中に略記されているものの規範的識別子がテーブルに完全なURIであることに注意してください「＆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
アルゴリズムタイプアルゴリズム - 要件 - アルゴリズムURIダイジェストSHA1 - 必須 - ＆DSIG、SHA1エンコードBASE64 - 必須 - ＆DSIG、BASE64 MAC HMAC-SHA1 - REQUIRED - ＆DSIG、HMAC-SHA1署名DSAwithSHA1（DSS） - 必須 - ＆DSIG。 DSA-SHA1 RSAwithSHA1 - 推奨 - ＆DSIG、RSA-SHA1の正規化、最小 - 推奨 - ＆DSIG;コメントと最小限の正規XML - 推奨 - http://www.w3.org/TR/2000/CR-xml-c14n-20001026正規XML（コメントは省略）#WithComments - 必須 - オプション - - http://www.w3.org/TR/2000/CR-xml-c14n-20001026は、XSLT変換http://www.w3.org/TR/1999 / REC-XSLT-19991116のXPath - 推奨 - http://www.w3.org/TR/1999/REC-xpath-19991116エンベロープ署名* - REQUIRED - ＆DSIG;エンベロープ署名
* 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つの以上の追加の強いダイジェストアルゴリズムは、米国のAdvanced Encryption Standardの努力に関連して開発されると予想されます。暗号の最近の進歩は、その強さに疑問を投げかけているので、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"/>
SHA-1アルゴリズム[SHA-1]は、明示的なパラメータを取りません。 SHA-1 DigestAlg要素の例は、<DigestMethodアルゴリズム= "＆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オクテットのオクテットストリームとして見このビット列のbase64エンコーディングでなければなりません。例えば、メッセージのDigestValue要素は、ダイジェスト：A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be: <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
SHA-1規格の付録Aからなり<DigestValue> qZk + NkcGgWq6PiVxeFDCbJzQ2J0 = </ DigestValue>
MAC algorithms take two implicit parameters, their keying material determined from KeyInfo and the octet stream output by CanonicalizationMethod. MACs and signature algorithms are syntactically identical but a MAC implies a shared secret key.
MACアルゴリズムは、二つの暗黙のパラメータ、CanonicalizationMethodにするKeyInfoによってオクテットストリーム出力から求め、それらの鍵材料を取ります。 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>
<のSignatureMethodアルゴリズム= "＆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
HMACアルゴリズムの出力は、最終的に選択されたダイジェストアルゴリズムの出力（おそらくは切り捨て）です。この値は、ダイジェストアルゴリズムの出力と同じ簡単な方法でbase64エンコードされなければなりません。例：HMAC-SHA1ダイジェストのためのSignatureValue要素
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:
<要素名= "HMACOutputLength" タイプ= "整数" /> DTD：
<!ELEMENT HMACOutputLength (#PCDATA)>
<！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.
署名アルゴリズムは、二つの暗黙のパラメータ、CanonicalizationMethodにするKeyInfoによってオクテットストリーム出力から求め、それらの鍵材料を取ります。署名と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"/>
<のSignatureMethodアルゴリズム= "＆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エンコーディングから成ります。整数オクテットストリームへの変換は、16進数で指定された値を持つ例えば20に等しいAKパラメータを使用してRFC 2437 [PKCS1明細書、DSA署名のためのSignatureValue要素（R、S）で定義され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
DSS規格の付録5の例から、R = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 S = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8であろう
<SignatureValue> i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==</SignatureValue>
<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、種子及びpgenCounterは任意であるが、存在すべきです。 （種子及び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:
<要素名= "DSAKeyValue"> <complexTypeの> <シーケンス> <シーケンス> <要素名= "P" タイプ= "DS：CryptoBinary" /> <要素名= "Q" タイプ= "DS：CryptoBinary" /> <要素名= "G" タイプ= "DS：CryptoBinary" /> <要素名= "Y" タイプ= "DS：CryptoBinary" /> <要素名= "J" タイプ= "DS：CryptoBinary" のminOccurs = "0" /> </配列> <配列のminOccurs = "0"> <要素名= "シード" タイプ= "DS：CryptoBinary" /> <要素名= "PgenCounter" タイプ= "DS：CryptoBinary" /> </シーケンス> </シーケンス> </ complexTypeの> </要素> 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) >
<！ELEMENT DSAKeyValue（P、Q、G、Y、J？（シード、PgenCounter）？）> <！ELEMENT P（#PCDATA）> <！ELEMENT Q（#PCDATA）> <！ELEMENT G（#PCDATA） > <！ELEMENT Y（#PCDATA）> <！ELEMENT J（#PCDATA）> <！ELEMENTシード（#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のラルモジュラスとして「bignums」）は、オクテットストリングとしてXMLで表現されています。整数値は、最初の「ビッグエンディアン」ビット列に変換されます。ビット文字列は、その後、ビット== 0 MOD 8（バイトの偶数であるように）の合計数ように先行ゼロビットでパディングされます。ビット列がゼロで全体をリードするバイトが含まれている場合、これらは削除されます（その上位バイトは常にゼロです）。このオクテットストリングは、その後、[MIME]はbase64エンコードです。 （整数からオクテットストリングへの変換は、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要素の例である：<のSignatureMethodアルゴリズム= "＆DSIG、RSA-SHA1" />
The SignatureValue content for an RSA signature is the base64 [MIME] encoding of the octet string computed as per RFC 2437 [PKCS1, section 8.1.1: Signature generation for the RSASSA-PKCS1-v1_5 signature scheme]. As specified in the EMSA-PKCS1-V1_5-ENCODE function RFC 2437 [PKCS1, section 9.2.1], the value input to the signature function MUST contain a pre-pended algorithm object identifier for the hash function, but the availability of an ASN.1 parser and recognition of OIDs is not required of a signature verifier. The PKCS#1 v1.5 representation appears as:
RSA署名のためのSignatureValueコンテンツがRFC 2437に従って計算オクテットストリングのBASE64 [MIME]符号化である[PKCS1、セクション8.1.1：署名生成RSASSA-PKCS1-v1_5の署名方式のために]。 [PKCS1、セクション9.2.1] EMSA-PKCS1-v1_5のエンコード機能RFC 2437に指定されるように、署名関数への入力値は、ハッシュ関数の事前保留アルゴリズムのオブジェクト識別子が、ASNの可用性を含まなければなりません0.1パーサーとOIDの認識は、署名検証に必要とされません。 PKCS＃1 v1.5の表現は次のようになります。
CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
CRYPT（PAD（ASN.1（OID、DIGEST（データ））））
Note that the padded ASN.1 will be of the following form:
パッド入りのASN.1は、次のような形式のものであろうことに注意してください。
01 | FF* | 00 | prefix | hash
01 | FF * | 00 |接頭辞|ハッシュ
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,
ここで、「|」 concatentation、「01」、「FF」、及び「00」は、対応する16進値の固定されたオクテットであり、「ハッシュ」は、データの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 0E 2B 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要素の子テキストノードの値であります
<SignatureValue>IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4 t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw= </SignatureValue>
<SignatureValue> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4 T0 / gyTE96639In0FZFY2 / RVP + / bMJ01EArmKZsR5VW3rwoPxw = </ SignatureValue>
RSA key values have two fields Modulus and Exponent
RSAキーの値は、二つのフィールドモジュラスと指数を持っています
<RSAKeyValue>
<RSAKeyValue>
<Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
<弾性率> xA7SEU + e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV 5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U= </Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue>
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV 5foK5hhmbktQhyNdy / 6LpQRhDUDsTvK + g9Ucj47es9AQJ3U = </弾性率> <指数> AQAB </指数> </ RSAKeyValue>
Schema:
スキーマ：
<element name="RSAKeyValue"> <complexType> <sequence> <element name="Modulus" type="ds:CryptoBinary"/> <element name="Exponent" type="ds:CryptoBinary"/> </sequence> </complexType> </element> DTD:
<要素名= "RSAKeyValue"> <complexTypeの> <シーケンス> <要素名= "モジュラス" タイプ= "DS：CryptoBinary" /> <要素名= "指数" タイプ= "DS：CryptoBinary" /> </シーケンス> </ complexTypeの> </要素> DTD：
<!ELEMENT RSAKeyValue (Modulus, Exponent) > <!ELEMENT Modulus (#PCDATA) > <!ELEMENT Exponent (#PCDATA) >
<！ELEMENT RSAKeyValue（モジュラス、指数）> <！ELEMENTモジュラス（#PCDATA）> <！ELEMENT指数（#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.
正規化は、オクテット上で実行されている場合は、正規化アルゴリズムは、2つの暗黙のパラメータを取る：コンテンツとその文字セットを。文字セット（例えば、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に非Unicodeエンコーディングからトランスコード。 2つのアルゴリズムは、以下の[NFC]トランスコーディング中にテキストの正規化を行います。私たちは、外部から指定された正規化アルゴリズムは同じことを行うことをお勧めします。 （例えば、XML日本語プロファイル[XML-日本語]注記を参照、Unicodeに既存の文字セットを変換する際にあいまいさが存在することができることに注意してください。）
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"/>
最小の正規化要素の例である：<CanonicalizationMethodにアルゴリズム=「＆DSIG;最小の」/>
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).)
*（任意のバイトオーダーマーク（BOM）なし）UTF-8に文字コードを変換します。エンコーディングはXML宣言で指定された場合、それを削除する必要があります。実装は、入力された符号化として、少なくとも[UTF-8]、[UTF-16]を理解しなければなりません。非Unicode Unicodeへのトランスコーディングは、[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).
このアルゴリズムは入力として処理されるべきリソースのオクテットストリームを必要とします。このアルゴリズムは、オクテットストリームを出力します。アルゴリズムはCanonicalizationMethodに要素（セクション4.3.1）に記載されているように整形SignedInfoエレメントを表すオクテット（とその子とコンテンツ）を備えていなければならないた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
REQUIRED正規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
コメント付きCanonicalはXMLのための識別子：http://www.w3.org/TR/2000/CR-xml-c14n-20001026#WithComments
An example of an XML canonicalization element is:
XMLの正規化要素の例は次のとおりです。
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
<CanonicalizationMethodにアルゴリズム= "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.
（そのような正規化アルゴリズム（セクション6.5）のもののような）CanonicalizationMethodにするために使用することができる任意の正規化アルゴリズムを変換として使用することができます。
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を適用::テキスト（）、次いで2）撮影ノードセットの文字列値。したがって、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ノード設定されている場合、ノードコメントことに注意が省略されているであろう。実際の入力は、オクテットストリームである場合、アプリケーションは、XPathノードセットのコメントを有するカノニカルXMLによる使用に適した（REQUIRED正規の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 2にコンテキスト位置とサイズを設定する//（XPath式を評価します。| // @ * | //名前空間:: *）
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式は、入力されたノードセット内のノードごとに一度だけ評価されます。結果は、ブール値に変換されます。ブール値がtrueの場合、ノードは、出力ノードセットに含まれています。ブール値が偽である場合、ノードは、出力ノードセットから省略されています。
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>こんにちは、<！ - コメント - >！世界は</ E>は、2つのテキスト・ノードが含まれています。したがって、表現の自己::テキスト（）[文字列（）= "こんにちは、世界！"]は失敗します。この問題は、XPath式の自己を使用することにより、例えば（物理的に親要素の文字列値に基づいて、ノードを照合することによって、コメントを削除したりするために変換する前に、それはどちらかの文書をcanonicalizingによって解決することができ、アプリケーションで発生する必要があります::テキスト（ ）[文字列（親:: E）= "こんにちは、世界！"]）。
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の署名を追加することは、第1の署名を壊さないように、最初の署名のダイジェスト計算から第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式は、サイズと位置変換が自動的にすべての訪問しているという事実を反映するために、常に1であることを除いて、使用[XSLT]でで使用されるものと非常によく似ていますノード（XSLTで、1は、再帰的に入力ツリーのノードを訪問するコマンド適用-テンプレートを呼び出します）。
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.
ここで、関数、属性、または処理命令ノード、または直接XPath式を担うテキストノードの親要素を含むノードセットを返します。含むXPath式は、XPath式が評価され、これに対して、同じXMLドキュメントに表示されない場合、この式はエラーになります。
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,
一例として、エンベロープ署名（署名される要素の子孫であるSignature要素）を作成することを検討。署名されたコンテンツは、署名後に変更されるべきではないが、Signature要素内の要素が変更されている（例えば、ダイジェスト値はDigestValueとSignatureValueの中に置かれなければならない続いて計算されなければなりません）。 DigestValueでダイジェスト値を無効から、これらの変更を防止するための一つの方法は、それがすべての署名要素とその子孫を省略変換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>
<ドキュメント> <署名のxmlns = "＆DSIG;"> <たSignedInfo> ... <参考URI = ""> <トランスフォーム> <アルゴリズム=トランスフォーム "http://www.w3.org/TR/1999/REC-をXPathの-19991116 "> <たXPathのxmlns：DSIG =" ＆DSIG; ">しない（祖先-又は自己:: DSIG：署名）</ XPathの> </変換> </トランスフォーム> <DigestMethodアルゴリズム=" HTTP：/ /www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue> </ DigestValue> </参照> </たSignedInfo> <SignatureValue> </ SignatureValue> </署名> ... </ドキュメント>
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の変換入力ノードセットは、（コメントノードを除く）は、ルートノードから始まる全体の解析ツリー内のすべてのノードを含んでいます。このノードセット内の各ノードについて、ノードは、ノードまたはその祖先の一つはエンティティの置換テキスト＆DSIG ;.によって指定された名前空間にある署名のタグを持っている場合を除き、ノードは、設定された出力に含まれています
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:
よりエレガントな解決策は、ここにこうしてエンベロープ署名が他の署名に署名することができ、XPathの変換を含むのみ署名を省略するように機能する使用します。上記の例では、XPathの要素を使用します。
<XPath xmlns:dsig="&dsig;"> count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) > count(ancestor-or-self::dsig:Signature)</XPath>
<のXPathのxmlns：DSIG = "＆DSIG;">数（祖先-または自己:: DSIG：署名|ここで（）/祖先:: DSIG：署名[1]）>数（祖先-または自己:: DSIG ：署名）</ 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等価演算子は、比較の前に文字列値にノードセットを変換しているので、我々は代わりのXPath union演算子を使用する必要があります。ノードとその署名要素の祖先を含むノードセットは、XPath式を含むエンベロープ署名要素を含んでいない場合にのみ、及び（組合があれば、より大きなセットを生成しない場合、文書の各ノードに対して、述語式が真でありますエンベロープ署名要素は、先祖または自己::シグネチャ）によって与えられたノードセットです。
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は、XML生産要素と署名と一致するXMLプロセッサによって使用される文字の文字列全体が除去されたT.を含む参照素子のダイジェスト計算からTを含む全体のSignature要素を除去します。変換の出力は、次のXPathパラメータ要素を含む変換するXPathとTを交換から生じる出力と等価です。
<XPath xmlns:dsig="&dsig;"> count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) > count(ancestor-or-self::dsig:Signature)</XPath>
<のXPathのxmlns：DSIG = "＆DSIG;">数（祖先-または自己:: DSIG：署名|ここで（）/祖先:: DSIG：署名[1]）>数（祖先-または自己:: DSIG ：署名）</ 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式エバリュエータを使用する必要はないことに注意してください。しかし、これは、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：スタイルシート>であるべきです。
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は出力正規化を実行transformto transformafterを挿入することをお勧めします。これらの手順は、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.
本明細書を通して、我々はSignature要素と他の署名されたXMLデータオブジェクトの正規化を区別します。変更が発生しないことができるように、それはバイナリデータであるかのように単離されたXML文書を処理することが可能です。その場合には、文書のダイジェストは変更されませんし、それが署名し、そのように検証された場合には、正規化する必要はありません。しかし、標準的なXML構文解析および処理技術を使用して読み取られ、処理されるXMLは、しばしば、その表面表示情報の一部が失われたり変更されるように変更されます。特に、これは、署名のために多くの場合に起こるであろうと、彼ら、そしておそらく包含するXML文書は、XMLとして処理されるので、要素たSignedInfo囲ま。
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.
同様に、これらの考慮事項は、オブジェクトをマニフェストに適用され、それらの要素が消化されている場合はSignatureProperties要素は、彼らのDigestValueをチェックする、と彼らは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]、または同様の処理に関連するものがあります。そして、第三の、そのようなすべての[XML]準拠プロセッサがサポートする必要があるどちらも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]の両方について文字の正規化を提供します。我々は、署名アプリケーションは、[NFC]正規化形式CのXMLコンテンツ（署名要素およびそれらの子孫/コンテンツ）を作成し、消費されて、任意のXMLが（ない場合、署名は、その結果の検証に失敗することがあり）、ならびにその形態であることを確認することをお勧めします。さらに、これらのアルゴリズムのどれもデータ型の正規化を提供しません。変化するフォーマットでデータタイプを正規化する（例えば、（真、偽）または（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が続いている場合#xD文字を落とし、他のすべてのケースでの#xAに置き換えることにより、単一の文字の#xAに正規化され、2不足している属性がに提供されるデフォルト値を持つように宣言しますアプリケーションは、デフォルト値を持つ存在する場合のように、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.実体参照は、対応する宣言エンティティに置き換えられ、前記属性値は、Aは、Bが＃1 X20（スペース）を除くと＃1 X9、の#xA、及び#xDの発生を置き換え、上記のように文字やエンティティ参照を置換することによって正規化されますシーケンス番号の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または同様の宣言の存在に依存することに留意されたいです。 Signature要素のタイプは、結果として、署名と同じドキュメント内の外部XMLあるいはXMLは（のみ）、ウェル形成、または（署名スキーマによって許可）別の名前空間からのものであってもよい、laxlyスキーマ妥当[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.属性のデフォルト値が明示的に存在することを有する、前記全てのエンティティ参照は（「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アプリケーションはドキュメントオブジェクトモデル[DOM]またはXML [SAX]用のシンプルな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
XML署名は、DOMまたはSAX処理を使用してシステム上に生成または検証される場合、カノニカル方法は、SAXイベントのDOMツリーまたは配列の関連部分をシリアル化するために必要とされます。このような[XML-C14N]としてXML正規化仕様は、唯一のDOMとSAXによって保存された情報に基づいています。 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.
前のセクションで与えられたXML1.0構文制約が従わなければならないが、適切なXML正規化は、にベリファイアを再シリアライズすることができるようにDOM / SAX媒介入力に指定されなければならないだけでなく、DOMやSAXを使用して実装することによって検証すべき署名署名したのと同じオクテットストリーム。
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-署名-RD、セクション3.1.3]を参照）。トランスフォーム機構は、識別されたリソースのコンテンツを処理から得られたデータに署名するために1つを可能にすることによって、この要件を満たしています。たとえば、フォームに署名することを希望するが、ユーザーがフォーム上の以前の署名を無効にすることなく限られたフィールドデータを入力することを許可したアプリケーションは、ユーザーが変更する必要がある部分を除外するために、[XPathの]使用する場合があります。変換は、任意に指定することができ、コード変換、正規化命令あるいはXSLT変換を含むことができます。三つの注意事項は、次のセクションでは、この機能に関連して提起されています。
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
カノニカルXML [XML-C14N]の使用は、すべての内部エンティティとXML名前空間が署名されているコンテンツ内で拡張されることを確実にすることに留意されたいです。すべてのエンティティは、その定義と明示的要素がそうでなければ継承する名前空間を表している標準的な形式に置き換えられます。 XMLコンテンツを正規化していないアプリケーション（特にSignedInfoエレメント）すべきです
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.
内部エンティティを使用して、彼らは彼らのためにこれを行うために正規化に頼ることができないので、署名されているコンテンツの中に明示的に名前空間を表現して下さいませ。
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プロセッサに署名有効性が、材料に対して正規化し、その結果取るに足らないある変化を導入できました。例えば、文字の大文字と小文字を変更することで、1は、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.
公開鍵署名では、当事者の任意の数は、公開鍵を保持し、秘密鍵でのみ当事者が署名を作成することができますしながら、署名を検証することができます。秘密鍵の所有者の数は最小限に抑えられ、好ましくは一つであるべきです。彼らが使用していて、その対応する秘密鍵によって表されるエンティティまたは機能に結合する公開鍵で検証することによって信頼感は重要な問題で、通常、証明書またはオンライン機関のシステムによって対処されます。
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.
この仕様は、ユーザー提供の署名アルゴリズムとキーイング情報指定子を可能にします。このようなユーザーに提供するアルゴリズムは、異なるセキュリティモデルを有することができます。例えば、バイオメトリクスを含む方法は、通常、公開または秘密鍵をすることができ、他のセキュリティモデルの違いを有することができる方法を変更することはできません許可されたユーザの物理的特性に依存します。
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.
特定の署名の強さは、セキュリティチェーン内のすべてのリンクに依存します。これは、署名を含み、ダイジェストアルゴリズムを用い、鍵生成の強度[RANDOM]とキーのサイズ、キーおよび証明書の認証と流通機構のセキュリティ、証明書チェーンの検証ポリシー、敵対的な観察や改ざんから暗号処理の保護など
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].
20000922スキーマ/ DTD [XML-スキーマ]に基づいて、XML署名スキーマのインスタンスhttp://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd有効なXMLスキーマ・インスタンス。
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-20000112.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署名例及びグレKarlingerによって検証。
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署名要素オブジェクト。 Object要素は、リファレンスを介して署名することができるデジタルデータ（または文書）の単なる一のタイプです。
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.
署名、本明細書の必須（REQUIRED /なければならない）の部分を実装するアプリケーションのアプリケーション。これらの適合要件は署名要素のタイプ及び（SignatureValueを含む）およびアルゴリズムをサポートするために必須の子の構造の上にあります。
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).
署名は、署名を包むこと署名自体のObject要素内に見出されるコンテンツ上にあります。オブジェクト（あるいはそのコンテンツ）を参照（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文書の要素を提供します。明らかに、包ま署名はSignatureValueの計算では、独自の値を含めないように注意する必要があります。
Transform The processing of a octet stream from source content to derived content. Typical transforms include XML Canonicalization, XPath, and XSLT.
誘導されたコンテンツソースのコンテンツからのオクテットストリームの処理を変換します。典型的な変換はXML正規化、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.
検証は、識別され、形質転換されたコンテンツのハッシュ値を参照、参照によって指定、その指定されたDigestValueと一致します。
Validation, Signature The SignatureValue matches the result of processing SignedInfo with CanonicalizationMethod and SignatureMethod as specified in Core Validation (section 3.2).
検証は、署名SignatureValueは、コア検証（セクション3.2）で指定されるようにCanonicalizationMethodにとのSignatureMethodと共にたSignedInfoを処理した結果と一致します。
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の属性。ロン・ブーレ。 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. Apparao、S.バーン、M.チャンピオン、S.アイザックス、I.ジェイコブス、A.ルオードブル、G.ニコル、J. Robie、R. Sutor、C.ウィルソン、L.ウッド。 1998年10月http://www.w3.org/TR/1998/REC-DOM-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
FIPS PUB 186-1 DSS。デジタル署名標準（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.、ベラー、M.とR.カネッティ、 "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フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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
KEYWORDSブラドナーの、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ワール、M.、Kille、S.とT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（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.、 "MD5メッセージダイジェストアルゴリズム"、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フリード、N.とN. Borenstein、「マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット」、RFC 2045、1996年11月http://www.ietf.org/rfc/rfc2045.txt
NFC TR15. Unicode Normalization Forms. M. Davis, M. Drst. Revision 18: November 1999.
NFC TR15。 Unicode正規化フォーム。 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カラス、J.、Donnerhacke、L.、フィニー、H.とR.セイヤー、 "OpenPGPのメッセージ形式"、1998年11月http://www.ietf.org/rfc/rfc2440.txt
RANDOM Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. http://www.ietf.org/rfc/rfc1750.txt
RANDOMイーストレイク、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. Brickleyが、R.V.グハ。 2000年3月http://www.w3.org/TR/2000/CR-rdf-schema-20000327/ RDFモデルとシンタックスW3C勧告。 O. Lassila、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.と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デイビット・メギンソンらのためのシンプルな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ホフマン、P.およびF. Yergeau、 "UTF-16、ISO 10646のエンコーディング"、RFC 2781、2000年2月http://www.ietf.org/rfc/rfc2781.txt
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バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、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
"URLの中にリテラルIPv6アドレスのフォーマット" URI-リテラルHindenとR.、大工、B.およびL. Masinter、RFC 2732、1999年12月http://www.ietf.org/rfc/rfc2732.txt
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バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（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堀、R.、 "URN構文" 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
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. Raggett、ら。アル。 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. DeRose、D.オーチャード、B.トラッフォード。 1999年7月http://www.w3.org/1999/07/WD-xlink-19990726
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. Sperberg-マックイーン。 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.ボワイエ、 "標準的な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-日本のXML日本語プロファイル。 W3C NOTE。 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ホワイトヘッド、E.およびM.村田、 "XMLのメディアタイプ"、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勧告でXML-nsの名前空間。 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スキーマXMLスキーマパート1：構造ワーキングドラフト。 D.ブナ、M.マロニー、N. Mendelshohn。 2000年9月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-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-署名-RD Reagle、J.、 "XML署名の要件"、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パス言語（XPath）バージョン1.0。勧告。 J.クラーク、S. DeRose。 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. DeRose、R.ダニエル、E. MALER。 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拡張スタイルシート言語（XSL）ワーキングドラフト。 S.アドラー、A.ベルグルンド、J.カルーソ、S.ディーチ、P.グロッソ、E. Gutentag、A. Milowski、S.パーネル、J.リッチマン、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-19991116.html
Donald E. Eastlake 3rd Motorola, Mail Stop: M2-450 20 Forbes Boulevard Mansfield, MA 02048 USA
ドナルドE.イーストレーク第3モトローラ、メールストップ：M2-450 20フォーブス大通りマンスフィールド、MA 02048 USA
Phone: 1-508-261-5434 EMail: Donald.Eastlake@motorola.com
電話：1-508-261-5434 Eメール：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
ジョセフM. Reagleジュニア、コンピュータサイエンスNE43-350のための技術研究所のW3Cマサチューセッツ工科大学、545テクノロジースクエアケンブリッジ、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
デビッド・ソロシティグループ909サードアベニュー、16階ニューヨーク、NY 10043 USA
Phone: +1-212-559-2900 EMail: dsolo@alum.mit.edu
電話：+ 1-212-559-2900 Eメール：dsolo@alum.mit.edu
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。