Network Working Group D. Eastlake 3rd
Request for Comments: 3275 Motorola
Obsoletes: 3075 J. Reagle
Category: Standards Track W3C
D. Solo
Citigroup
March 2002
(Extensible Markup Language) XML-Signature Syntax and Processing
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2002 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
著作権（C）2002ザ・インターネット協会＆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.1 Editorial and Conformance Conventions......................... 4
1.2 Design Philosophy............................................. 4
1.3 Versions, Namespaces and Identifiers.......................... 4
1.4 Acknowledgements.............................................. 6
1.5 W3C Status.................................................... 6
2. Signature Overview and Examples................................ 7
2.1 Simple Example (Signature, SignedInfo, Methods, and References) 8
2.1.1 More on Reference........................................... 9
2.2 Extended Example (Object and SignatureProperty)............... 10
2.3 Extended Example (Object and Manifest)........................ 12
3.0 Processing Rules.............................................. 13
3.1 Core Generation............................................... 13
3.1.1 Reference Generation........................................ 13
3.1.2 Signature Generation........................................ 13
3.2 Core Validation............................................... 14
3.2.1 Reference Validation........................................ 14
3.2.2 Signature Validation........................................ 15
4.0 Core Signature Syntax......................................... 15
4.0.1 The ds:CryptoBinary Simple Type............................. 17
4.1 The Signature element......................................... 17
4.2 The SignatureValue Element.................................... 18
4.3 The SignedInfo Element........................................ 18
4.3.1 The CanonicalizationMethod Element.......................... 19
4.3.2 The SignatureMethod Element................................. 21
4.3.3 The Reference Element....................................... 21
4.3.3.1 The URI Attribute......................................... 22
4.3.3.2 The Reference Processing Model............................ 23
4.3.3.3 Same-Document URI-References.............................. 25
4.3.3.4 The Transforms Element.................................... 26
4.3.3.5 The DigestMethod Element.................................. 28
4.3.3.6 The DigestValue Element................................... 28
4.4 The KeyInfo Element........................................... 29
4.4.1 The KeyName Element......................................... 31
4.4.2 The KeyValue Element........................................ 31
4.4.2.1 The DSAKeyValue Element................................... 32
4.4.2.2 The RSAKeyValue Element................................... 33
4.4.3 The RetrievalMethod Element................................. 34
4.4.4 The X509Data Element........................................ 35
4.4.5 The PGPData Element......................................... 38
4.4.6 The SPKIData Element........................................ 39
4.4.7 The MgmtData Element........................................ 40
4.5 The Object Element............................................ 40
5.0 Additional Signature Syntax................................... 42
5.1 The Manifest Element.......................................... 42
5.2 The SignatureProperties Element............................... 43
5.3 Processing Instructions in Signature Elements................. 44
5.4 Comments in Signature Elements................................ 44
6.0 Algorithms.................................................... 44
6.1 Algorithm Identifiers and Implementation Requirements......... 44
6.2 Message Digests............................................... 46
6.2.1 SHA-1....................................................... 46
6.3 Message Authentication Codes.................................. 46
6.3.1 HMAC........................................................ 46
6.4 Signature Algorithms.......................................... 47
6.4.1 DSA......................................................... 47
6.4.2 PKCS1 (RSA-SHA1)............................................ 48
6.5 Canonicalization Algorithms................................... 49
6.5.1 Canonical XML............................................... 49
6.6 Transform Algorithms.......................................... 50
6.6.1 Canonicalization............................................ 50
6.6.2 Base64...................................................... 50
6.6.3 XPath Filtering............................................. 51
6.6.4 Enveloped Signature Transform............................... 54
6.6.5 XSLT Transform.............................................. 54
7. XML Canonicalization and Syntax Constraint Considerations...... 55
7.1 XML 1.0, Syntax Constraints, and Canonicalization............. 56
7.2 DOM/SAX Processing and Canonicalization....................... 57
7.3 Namespace Context and Portable Signatures..................... 58
8.0 Security Considerations....................................... 59
8.1 Transforms.................................................... 59
8.1.1 Only What is Signed is Secure............................... 60
8.1.2 Only What is 'Seen' Should be Signed........................ 60
8.1.3 'See' What is Signed........................................ 61
8.2 Check the Security Model...................................... 62
8.3 Algorithms, Key Lengths, Certificates, Etc.................... 62
9. Schema, DTD, Data Model, and Valid Examples.................... 63
10. Definitions................................................... 63
Appendix: Changes from RFC 3075................................... 67
References........................................................ 67
Authors' Addresses................................................ 72
Full Copyright Statement.......................................... 73
This document specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information.
この文書では、デジタル署名を作成し、表現するためのXML構文と処理規則を指定します。 XML署名はXMLを含め、任意のデジタルコンテンツ（データ・オブジェクト）に適用することができます。 XML署名は、1つまたは複数のリソースのコンテンツにも適用することができます。エンベロープ又は外被署名は、署名と同じXML文書内のデータ上です。分離署名は署名要素の外部にデータを超えています。より具体的には、この仕様は、XML署名要素タイプとXML署名アプリケーションを定義します。それぞれの適合性要件は、それぞれのスキーマ定義と散文の方法によって指定されています。この仕様は、他の有用なリソースのコレクションを参照するための方法を特定のタイプ、アルゴリズム、キーおよび管理情報を含みます。
The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements. For further information, please see Security Considerations (section 8).
XML署名は、参照データ（オクテット）でキーを関連付ける方法です。それは規範的にキーが人や機関に関連付けられている、またデータの意味が参照されていると署名方法を指定しません。本明細書は、安全なXMLアプリケーションの重要な成分であるが、結果として、それ自体が特に署名されたXML（または他のデータフォーマット）を使用に対するすべてのアプリケーションセキュリティ/信頼の問題に対処するのに十分ではない、人間対人間の基礎としてコミュニケーションと合意。このようなアプリケーションでは、追加のキー、アルゴリズム、処理およびレンダリング要件を指定する必要があります。詳細については、セキュリティに関する考慮事項（セクション8）を参照してください。
For readability, brevity, and historic reasons this document uses the term "signature" to generally refer to digital authentication values of all types. Obviously, the term is also strictly used to refer to authentication values that are based on public keys and that provide signer authentication. When specifically discussing authentication values based on symmetric secret key codes we use the terms authenticators or authentication codes. (See Check the Security Model, section 8.3.)
読みやすさ、簡潔さ、そして歴史的な理由から、この文書では、一般的に、すべてのタイプのデジタル認証値を参照するために用語「署名」を使用しています。明らかに、この用語はまた、厳密に公開鍵に基づいており、それは署名者の認証を提供している認証値を参照するために使用されます。特に対称秘密キーコードに基づいて認証値を議論するとき、我々は用語の認証者または認証コードを使用します。 （セキュリティモデル、セクション8.3をチェックしてください。）
This specification provides an XML Schema [XML-schema] and DTD [XML]. The schema definition is normative.
この仕様は、XMLスキーマ[XMLスキーマ]およびDTD [XML]を提供します。スキーマ定義は規範的です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:
この仕様でキーワード "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 key words to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the Namespaces in XML specification [XML-ns] is described as "REQUIRED."
その結果、我々は明確な実装の相互運用性とセキュリティに影響を与えるプロトコルおよびアプリケーション機能と動作上の要件を指定するには、これらの大文字のキーワードを使用します。これらのキーワードが使用されていないXMLの文法を記述するために（大文字）。スキーマ定義は明確な要件について説明し、我々はプロトコルや機能の自然言語記述のためにこれらの用語の隆起を確保したいです。例えば、XML属性があると記載される可能性があります「オプション。」 XML仕様の名前空間[XML-NS]に準拠は、以下のように記載されている「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:
いかなる規定は、この構文で明示的なバージョン番号のために作られていません。将来のバージョンが必要な場合は、それは別の名前空間を使用します。この実装で使用しなければならないXML名前空間[XML-NS] URI（日付）仕様です。
xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns = "http://www.w3.org/2000/09/xmldsig#"
This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "dsig" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.
この名前空間は、この仕様で使用されるアルゴリズム識別子の接頭辞として使用されています。アプリケーションは、XMLとXML名前空間、内部実体[XML]または当社の「DSIG」のXML名前空間接頭辞と債務不履行の使用をサポートする必要がありますが/スコープ規則はオプションです。私たちは、コンパクトで読みやすい例を提供するために、これらの施設を使用しています。
This specification uses Uniform Resource Identifiers [URI] to identify resources, algorithms, and semantics. The URI in the namespace declaration above is also used as a prefix for URIs under the control of this specification. For resources not under the control of this specification, we use the designated Uniform Resource Names [URN] or Uniform Resource Locators [URL] defined by its normative external specification. If an external specification has not allocated itself a Uniform Resource Identifier we allocate an identifier under our own namespace. For instance:
この仕様は、リソース、アルゴリズム、およびセマンティクスを識別するために、統一リソース識別子[URI]を使用しています。上記の名前空間宣言におけるURIはまた、本明細書の制御下URIの接頭辞として使用されます。この仕様の制御下にあるリソースではないために、私たちはその規範的な外部仕様で定義された指定された統一リソース名[URN]またはユニフォームリソースロケータ[URL]を使用します。外部仕様自体が割り当てられていない場合は統一資源識別子は、我々は我々自身の名前空間の下の識別子を割り当てます。例えば：
SignatureProperties is identified and defined by this specification's namespace: http://www.w3.org/2000/09/xmldsig#SignatureProperties
SignaturePropertiesは、この仕様の名前空間によって識別され、定義されていますhttp://www.w3.org/2000/09/xmldsig#SignatureProperties
XSLT is identified and defined by an external URI http://www.w3.org/TR/1999/REC-xslt-19991116
XSLTは、外部URI http://www.w3.org/TR/1999/REC-xslt-19991116によって識別され、定義されています
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, Accelio (Author) * John Boyer, PureEdge (Author) * Mariano P. Consens, University of Waterloo * John Cowan, Reuters Health * Donald Eastlake 3rd, Motorola (Chair, Author/Editor) * Barb Fox, Microsoft (Author) * Christian Geuer-Pollmann, University Siegen * Tom Gindin, IBM * Phillip Hallam-Baker, VeriSign Inc * Richard Himes, US Courts * Merlin Hughes, Baltimore * Gregor Karlinger, IAIK TU Graz * Brian LaMacchia, Microsoft (Author) * Peter Lipp, IAIK TU Graz * Joseph Reagle, W3C (Chair, Author/Editor) * Ed Simon, XMLsec (Author) * David Solo, Citigroup (Author/Editor) * Petteri Stenius, DONE Information, Ltd * Raghavan Srinivas, Sun * Kent Tamura, IBM * Winchel Todd Vincent III, GSU * Carl Wallace, Corsec Security, Inc. * Greg Whitehead, Signio Inc.
*マーク・バーテル、Accelio（著）*ジョン・ボワイエ、PureEdge（著）*マリアノP. Consens、ウォータールー*ジョン・コーワン大学、ロイターヘルス*ドナルドイーストレイク3日、モトローラ（椅子、著者/編集者）*バーブフォックス、マイクロソフト（著者）*クリスチャンGeuer-Pollmann、大学ジーゲン*トムGindin、IBM *フィリップハラム - ベイカー、ベリサイン社*リチャードHimes、米国裁判所*マーリン・ヒューズ、ボルチモア*グレゴールKarlinger、IAIK TUグラーツ*ブライアン・ラマキア、マイクロソフト（著）*ピーターLIPP、IAIK TUグラーツ*ジョセフReagle、W3C（椅子、著者/編集者）*エド・サイモン、XMLsec（著）*デビッド・ソロ、シティグループ（著者/編集者）* 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の代わりに。
The World Wide Web Consortium Recommendation corresponding to this RFC is at:
このRFCに対応したWorld Wide Web Consortium（W3C）の勧告はです：
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
ｈっｔｐ：／／ｗっｗ。ｗ３。おｒｇ／ＴＲ／２００２／れＣーｘｍｌｄしｇーこれー２００２０２１２／
This section provides an overview and examples of XML digital signature syntax. The specific processing is given in Processing Rules (section 3). The formal syntax is found in Core Signature Syntax (section 4) and Additional Signature Syntax (section 5).
このセクションでは、概要とXMLデジタル署名の構文の例を提供します。具体的な処理は、処理ルール（セクション3）で与えられます。正式な構文は、コア署名シンタックス（セクション4）および追加の署名シンタックス（セクション5）に見出されます。
In this section, an informal representation and examples are used to describe the structure of the XML signature syntax. This representation and examples may omit attributes, details and potential features that are fully explained later.
このセクションでは、非公式の表現および実施例は、XML署名の構文構造を記述するために使用されます。この表現および実施例は、完全に後述されている属性、詳細及び潜在的な機能を省略することができます。
XML Signatures are applied to arbitrary digital content (data objects) via an indirection. Data objects are digested, the resulting value is placed in an element (with other information) and that element is then digested and cryptographically signed. XML digital signatures are represented by the Signature element which has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences):
XML署名は間接を介して任意のデジタルコンテンツ（データオブジェクト）に適用されます。データ・オブジェクトが消化され、得られた値は（他の情報と）素子に配置され、その要素は、その後、消化し、暗号署名されています。 XMLデジタル署名は、以下の構造を有するSignature要素によって表される（「？」;「+」は、一つ以上の発生を示し、ゼロまたは1つの発生を表す「*」は0回以上の繰り返しを表します）：
<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature>
<署名ID？> <たSignedInfo> <CanonicalizationMethodに/> <のSignatureMethod />（<参考URI？>（<トランスフォーム>）？<DigestMethod> <DigestValue> </参照>）+ </たSignedInfo> <SignatureValue>（<のKeyInfo >）？ （<オブジェクトID？>）* </署名>
Signatures are related to data objects via URIs [URI]. Within an XML document, signatures are related to local data objects via fragment identifiers. Such local data can be included within an enveloping signature or can enclose an enveloped signature. Detached signatures are over external network resources or local data objects that reside within the same XML document as sibling elements; in this case, the signature is neither enveloping (signature is parent) nor enveloped attribute (signature is child). Since a Signature element (and its Id value/name) may co-exist or be combined with other elements (and their IDs) within a single XML document, care should be taken in choosing names such that there are no subsequent collisions that violate the ID uniqueness validity constraint [XML].
署名は、URIを[URI]を介してデータオブジェクトに関連しています。 XML文書内で、署名はフラグメント識別子を介してローカルデータオブジェクトに関連しています。そのようなローカルデータを包囲署名内に含まれ得るか、またはエンベロープ署名を囲むことができます。分離署名は、外部のネットワークリソースまたは兄弟要素と同じXML文書内に存在するローカルデータオブジェクトを超えています。この場合には、署名はどちらも包み込む（署名が親である）やエンベロープ属性（署名が子供である）です。以来Signature要素（及びそのID値/名）が共存し得るか、または他の要素（とそのID）と組み合わされて単一のXML文書内に、注意が違反後続衝突が存在しないように、名前を選択する際に注意しなければなりませんID一意性妥当性制約[XML]。
The following example is a detached signature of the content of the HTML4 in XML specification.
次の例では、XML仕様のHTML4のコンテンツの分離署名です。
[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> [s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> [s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> [s11] </Reference> [s12] </SignedInfo> [s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> [s14] <KeyInfo> [s15a] <KeyValue> [s15b] <DSAKeyValue> [s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y> [s15d] </DSAKeyValue> [s15e] </KeyValue> [s16] </KeyInfo> [s17] </Signature>
[S01] <署名ID = "MyFirstSignature" のxmlns = "http://www.w3.org/2000/09/xmldsig#"> [S02] <たSignedInfo> [S03] <CanonicalizationMethodにアルゴリズム= "HTTP：// WWW .w3.org / TR / 2001 / REC-XML-C14N-20010315 "/> [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 / 2001 / REC-XML-C14N-20010315 "/> [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. Note that this example, and all examples in this specification, are not in canonical form.
[S03] CanonicalizationMethodには、それが署名操作の一部として消化される前に、SignedInfoエレメントを正規化するために使用されるアルゴリズムです。すなわち、この例に注意し、そして本明細書中のすべての例は、標準形式ではありません。
[s04] The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the SignatureValue. It is a combination of a digest algorithm and a key dependent algorithm and possibly other algorithms such as padding, for example RSA-SHA1. The algorithm names are signed to resist attacks based on substituting a weaker algorithm. To promote application interoperability we specify a set of signature algorithms that MUST be implemented, though their use is at the discretion of the signature creator. We specify additional algorithms as RECOMMENDED or OPTIONAL for implementation; the design also permits arbitrary user specified algorithms.
[S04]のSignatureMethodはSignatureValueに正規化されたSignedInfoを変換するために使用されるアルゴリズムです。それは、例えば、RSA-SHA1ため、ダイジェストアルゴリズムと鍵に依存するアルゴリズム及びパディングなどのおそらく他のアルゴリズムの組み合わせです。アルゴリズム名は弱いアルゴリズムを置き換えるに基づく攻撃に抵抗するために署名されています。アプリケーションの相互運用性を促進するために、我々はそれらの使用は、署名作成者の裁量であるものの、実装しなければならない署名アルゴリズムのセットを指定します。私たちは、実装のために推奨またはオプションなどの追加のアルゴリズムを指定します。デザインも、任意のユーザーが指定したアルゴリズムを許可します。
[s05-11] Each Reference element includes the digest method and resulting digest value calculated over the identified data object. It may also include transformations that produced the input to the digest operation. A data object is signed by computing its digest value and a signature over that value. The signature is later checked via reference and signature validation.
【s05-11各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/2001/REC-xml-c14n-20010315"/> [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/2001/REC-xml-c14n-20010315 "/> [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, as opposed to 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, XPath, XML schema validation, or XInclude. XPath transforms permit the signer to derive an XML document that omits portions of the source document. Consequently those excluded portions can change without affecting signature validity. For example, if the resource being signed encloses the signature itself, such a transform must be used to exclude the signature value from its own computation. If no Transforms element is present, the resource's content is digested directly. While the Working Group has specified mandatory (and optional) canonicalization and decoding algorithms, user specified transforms are permitted.
[s06-08]トランスフォームは、それが消化される前に、リソースのコンテンツに適用された処理ステップのオプションの順序付きリストです。変換は、正規化、符号化/（圧縮/膨張含む）復号、XSLT、XPathの、XMLスキーマ検証、またはXIncludeのような操作を含むことができます。 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 (integrity, message authentication, and/or signer authentication). Applications that wish to represent other semantics must rely upon other technologies, such as [XML, RDF]. For instance, an application might use a foo:assuredby attribute within its own markup to reference a Signature element. Consequently, it's the application that must understand and know how to make trust decisions given the validity of the signature and the meaning of assuredby syntax. We also define a SignatureProperties element type for the inclusion of assertions about the signature itself (e.g., signature semantics, the time of signing or the serial number of hardware used in cryptographic processes). Such assertions may be signed by including a Reference for the SignatureProperties in SignedInfo. While the signing application should be very careful about what it signs (it should understand what is in the SignatureProperty) a receiving application has no obligation to understand that semantic (though its parent trust engine may wish to). Any content about the signature generation may be located within the SignatureProperty element. The mandatory Target attribute references the Signature element to which the property applies.
この仕様は、文または表明を行うためのメカニズムには対応していません。代わりに、このドキュメントでは、何かがXML署名（整合性、メッセージ認証、および/または署名者認証）によって署名されるため、それが何を意味するかを定義します。他のセマンティクスを表現したいアプリケーションは、[XML、RDF]など、他の技術、に依存している必要があります。 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> [p08] </SignedInfo> [p09] ... [p10] <Object> [p11] <SignatureProperties> [p12] <SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"> [p13] <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt"> [p14] <date>19990908</date> [p15] <time>14:34:34:34</time> [p16] </timestamp> [p17] </SignatureProperty> [p18] </SignatureProperties> [p19] </Object> [p20]</Signature>
[] <署名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#sha1" /> [P06] <DigestValue> k3453rvEPO0vKtMup4NbeVu8nk = </ DigestValue> [P07] </リファレンス> [P08] </たSignedInfo> [P09] .. [P10] <オブジェクト> [P11] <SignatureProperties> [P12] <SignatureProperty ID = "AMadeUpTimeStamp" TARGET = "＃1 MySecondSignature"> [P13] <タイムスタンプのxmlns = "http://www.ietf.org/rfcXXXX。 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 follow.
マニフェスト要素は、直接この仕様の必須の部分で扱われていない追加的な要件を満たすために提供されます。二つの要件やマニフェストは彼らが従う満たす方法。
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. 3. Create a Reference element, including the (optional) identification of the data object, any (optional) transform elements, the digest algorithm and the DigestValue. (Note, it is the canonical form of these references that are signed in 3.1.2 and validated in 3.2.1.)
アプリケーションによって決定されるような1データオブジェクトに、変換を適用します。 2.得られたデータオブジェクト上ダイジェスト値を計算します。前記データオブジェクトの（任意）の識別、任意（オプション）要素、ダイジェストアルゴリズムとDigestValue変換を含む、Reference要素を作成します。 （それは3.1.2で署名され、3.2.1で検証されているこれらの参考文献の標準形式であることに注意してください。）
1. Create SignedInfo element with SignatureMethod, CanonicalizationMethod and Reference(s). 2. Canonicalize and then calculate the SignatureValue over SignedInfo based on algorithms specified in SignedInfo.
1.のSignatureMethod、CanonicalizationMethodにおよびリファレンス（S）とのSignedInfoエレメントを作成します。 2.正規化した後たSignedInfoで指定されたアルゴリズムに基づいたSignedInfo上SignatureValueを計算します。
3. Construct the Signature element that includes SignedInfo, Object(s) (if desired, encoding may be different than that used for signing), KeyInfo (if required), and SignatureValue.
3.たSignedInfoを含むSignature要素を構築し、オブジェクト（複数可）（所望であれば、符号化は、署名に使用されるものとは異なっていてもよい）、のKeyInfo（必要な場合）、およびSignatureValue。
Note, if the Signature includes same-document references, [XML] or [XML-schema] validation of the document might introduce changes that break the signature. Consequently, applications should be careful to consistently process the document or refrain from using external contributions (e.g., defaults and entities).
文書の注意、署名が同じドキュメントの参照が含まれている場合、[XML]または[XMLスキーマ]検証署名を破る変化を導入することがあります。これにより、アプリケーションが一貫して文書を処理するか、外部の寄与（例えば、デフォルトとエンティティ）を使用して控えるように注意しなければなりません。
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を指定した間接参照することができない、または不本意の任意の部分を実装するために失敗を含みます
Comparison of values in reference and signature validation are over the numeric (e.g., integer) or decoded octet sequence of the value. Different implementations may produce different encoded digest and signature values when processing the same resources because of variances in their encoding, such as accidental white space. But if one uses numeric or octet comparison (choose one) on both the stated and computed values these problems are eliminated.
基準及び署名検証の値の比較は、数値（例えば、整数）、又は値のデコードされたオクテットシーケンスを超えています。同じリソースを処理するときに異なる実装があるため、このような偶発的なホワイトスペースとしてのそれらのエンコーディングのばらつき、異なる符号化されたダイジェストと署名値を生成することができます。 1が述べたと計算された値の両方に数値またはオクテットの比較を（いずれかを選択）を使用している場合でも、これらの問題が解消されます。
1. Canonicalize the SignedInfo element based on the CanonicalizationMethod in SignedInfo. 2. For each Reference in SignedInfo: 2.1 Obtain the data object to be digested. (For example, the signature application may dereference the URI and execute Transforms provided by the signer in the Reference element, or it may obtain the content through other means such as a local cache.) 2.2 Digest the resulting data object using the DigestMethod specified in its Reference specification. 2.3 Compare the generated digest value against DigestValue in the SignedInfo Reference; if there is any mismatch, validation fails.
1.のSignedInfoでCanonicalizationMethodに基づいてSignedInfoエレメントを正規化。 SignedInfo内の各リファレンス2.：2.1を消化するためにデータオブジェクトを取得します。 （例えば、署名アプリケーションは、URI間接参照することができ、そのようなローカルキャッシュとしてReference要素内の署名者によって提供される変換を実行し、又は、他の手段を介してコンテンツを取得してもよい。）2.2ダイジェストDigestMethodを使用して得られたデータオブジェクト内の指定されましたそのリファレンス仕様。 2.3のSignedInfo参考にDigestValueに対するダイジェスト生成された値を比較。任意の不一致がある場合、検証は失敗します。
Note, SignedInfo is canonicalized in step 1. The application must ensure that the CanonicalizationMethod has no dangerous side affects, such as rewriting URIs, (see CanonicalizationMethod (section 4.3)) and that it Sees What is Signed, which is the canonical form.
注意、のSignedInfoは、そのようなURIを書き換えるように、アプリケーションがCanonicalizationMethodには危険な側面を持っていないことを確認する必要がありますステップ1で影響正規化され、（）CanonicalizationMethodに（セクション4.3を参照）、それが標準的な形態である、署名されて何見ています。
1. Obtain the keying information from KeyInfo or from an external source. 2. Obtain the canonical form of the SignatureMethod using the CanonicalizationMethod and use the result (and previously obtained KeyInfo) to confirm the SignatureValue over the SignedInfo element.
1のKeyInfoから、または外部ソースから鍵情報を取得します。 2. CanonicalizationMethodにを使用してのSignatureMethodの標準形式を取得し、その結果を使用する（以前のKeyInfoを得た）SignedInfoエレメント上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, and internal entity.
XML署名の一般的な構造は、署名の概要（セクション2）に記載されています。このセクションでは、コア署名機能の詳細な構文を提供します。特に明記しない限り、このセクションで説明する機能を実装するために必須です。構文は、以下のXMLプリアンブル、宣言、および内部エンティティとDTDおよび[XML-スキーマ]を介して定義されます。
Schema Definition:
スキーマ定義：
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd" [ <!ATTLIST schema xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#"> <!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'> <!ENTITY % p ''> <!ENTITY % s ''> ]>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOCTYPEスキーマPUBLIC！ " - // W3C // DTD XMLスキーマ200102 // EN"「http://www.w3.org/2001/XMLSchema .DTD」[<ATTLISTスキーマのxmlns：！DS CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#"> <！ENTITYのDSIG「http://www.w3.org/2000/ 09 / XMLDSIGの＃ '> <！ENTITY％以下のP ''> <！ENTITY％sの ''>]>
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="http://www.w3.org/2000/09/xmldsig#" version="0.1" elementFormDefault="qualified">
<スキーマのxmlns = "http://www.w3.org/2001/XMLSchema" のxmlns：DS = "http://www.w3.org/2000/09/xmldsig#" のtargetNamespace = "のhttp：// WWW。 w3.org/2000/09/xmldsig#」バージョン= "0.1" のelementFormDefault = "資格">
DTD:
DTD：
<!--
<!ーー
The following entity declarations enable external/flexible content in the Signature content model.
次のエンティティ宣言は、署名コンテンツモデルにおける外部/柔軟なコンテンツを可能にします。
#PCDATA emulates schema:string; when combined with element types it emulates schema mixed="true".
#PCDATAは、スキーマをエミュレート：文字列;要素タイプと組み合わせた場合には=「true」に混合スキーマをエミュレートします。
%foo.ANY permits the user to include their own element types from other namespaces, for example: <!ENTITY % KeyValue.ANY '| ecds:ECDSAKeyValue'> ... <!ELEMENT ecds:ECDSAKeyValue (#PCDATA) >
％foo.ANYは、例えば、他の名前空間から、独自の要素タイプを含めるために、ユーザが許可されます。<！ENTITY％以下のKeyValue.ANY「| ECDは：！ECDSAKeyValue '> ... <ELEMENTのECDは：ECDSAKeyValue（#PCDATA）>
-->
ーー＞
<!ENTITY % Object.ANY ''> <!ENTITY % Method.ANY ''> <!ENTITY % Transform.ANY ''> <!ENTITY % SignatureProperty.ANY ''> <!ENTITY % KeyInfo.ANY ''> <!ENTITY % KeyValue.ANY ''> <!ENTITY % PGPData.ANY ''> <!ENTITY % X509Data.ANY ''> <!ENTITY % SPKIData.ANY ''>
<！ENTITY％Object.ANY ''> <！ENTITY％Method.ANY ''> <！ENTITY％Transform.ANY ''> <！ENTITY％SignatureProperty.ANY ''> <！ENTITY％以下のKeyInfo.ANY ''> <！ENTITY％KeyValue.ANY ''> <！ENTITY％PGPData.ANY ''> <！ENTITY％X509Data.ANY ''> <！ENTITY％以下のSPKIData.ANY ''>
This specification defines the ds:CryptoBinary simple type for representing arbitrary-length integers (e.g., "bignums") in XML as octet strings. The integer value is first converted to a "big endian" bitstring. The bitstring is then padded with leading zero bits so that the total number of bits == 0 mod 8 (so that there are an integral number of octets). If the bitstring contains entire leading octets that are zero, these are removed (so the high-order octet is always non-zero). This octet string is then base64 [MIME] encoded. (The conversion from integer to octet string is equivalent to IEEE 1363's I2OSP [1363] with minimal length).
この仕様は、DSを定義する：任意の長さの整数を表すCryptoBinary単純型（例えば、「bignums」）XMLでオクテットストリングとして。整数値は、最初の「ビッグエンディアン」ビット列に変換されます。ビット文字列は、その後、ビット== 0 MOD 8（オクテットの整数が存在するように）の合計数ように先行ゼロビットでパディングされます。ビット列がゼロで全体をリードするオクテットが含まれている場合、これらは削除されます（その上位オクテットは常にゼロです）。このオクテットストリングは、その後、[MIME]はbase64エンコードです。 （整数からオクテットストリングへの変換は、IEEE 1363のI2OSP【1363】最小の長さに相当します）。
This type is used by "bignum" values such as RSAKeyValue and DSAKeyValue. If a value can be of type base64Binary or ds:CryptoBinary they are defined as base64Binary. For example, if the signature algorithm is RSA or DSA then SignatureValue represents a bignum and could be ds:CryptoBinary. However, if HMAC-SHA1 is the signature algorithm then SignatureValue could have leading zero octets that must be preserved. Thus SignatureValue is generically defined as of type base64Binary.
このタイプは、RSAKeyValueとDSAKeyValueとして「BIGNUM」値によって使用されます。値の型がbase64Binaryのか、DSのものとすることができる場合は、次のCryptoBinaryそれらはbase64Binaryのように定義されています。署名アルゴリズムは、RSA又はDSAである場合、例えば、次にSignatureValueはBIGNUMを表し、DSであり得る：CryptoBinary。 HMAC-SHA1が署名アルゴリズムである場合しかし、その後、SignatureValueは保存されなければならない先行ゼロのオクテットを持つことができます。したがってSignatureValueを総称型base64Binaryののように定義されます。
Schema Definition:
スキーマ定義：
<simpleType name="CryptoBinary"> <restriction base="base64Binary"> </restriction> </simpleType>
<単純名= "CryptoBinary"> <制限ベース= "base64Binaryの"> </制限> </ simpleTypeの>
The Signature element is the root element of an XML Signature. Implementation MUST generate laxly schema valid [XML-schema] Signature elements as specified by the following schema:
Signature要素は、XML署名のルート要素です。次のスキーマで指定された実装は、署名要素laxlyスキーマ有効[XMLスキーマ]を生成する必要があります
Schema Definition:
スキーマ定義：
<element name="Signature" type="ds:SignatureType"/> <complexType name="SignatureType"> <sequence> <element ref="ds:SignedInfo"/> <element ref="ds:SignatureValue"/> <element ref="ds:KeyInfo" minOccurs="0"/> <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType>
<要素名= "署名" タイプ= "DS：SignatureType" /> <complexTypeの名前= "SignatureType"> <シーケンス> <要素REF = "DS：たSignedInfo" /> <要素REF = "DS：SignatureValue" /> <要素REF = "DS：KeyInfoの" minOccurs属性= "0" /> <要素REF = "DS：オブジェクト" のminOccurs = "0" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "ID" タイプ=」 ID」使用= "オプション" /> </ complexTypeの>
DTD:
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 identify two SignatureMethod algorithms, one mandatory and one optional to implement, user specified algorithms may be used as well.
SignatureValue要素は、デジタル署名の実際の値を含みます。それは、常にbase64で[MIME]を使用してエンコードされます。我々は実現するために2つのSignatureMethodアルゴリズム、必須の1つずつオプションを識別しながら、ユーザが指定したアルゴリズムを用いてもよいです。
Schema Definition:
スキーマ定義：
<element name="SignatureValue" type="ds:SignatureValueType"/> <complexType name="SignatureValueType"> <simpleContent> <extension base="base64Binary"> <attribute name="Id" type="ID" use="optional"/> </extension> </simpleContent> </complexType>
<要素名= "SignatureValue" タイプ= "DS：SignatureValueType" /> <complexTypeの名= "SignatureValueType"> <simpleContentを> <拡張基地= "base64Binaryの"> <属性名= "ID" タイプ= "ID" 使用=」オプション "/> </拡張> </ simpleContentを> </ complexTypeの>
DTD:
DTD：
<!ELEMENT SignatureValue (#PCDATA) > <!ATTLIST SignatureValue Id ID #IMPLIED>
<！ELEMENT SignatureValue（#PCDATA）> <！ATTLIST SignatureValueイドID #IMPLIED>
The structure of SignedInfo includes the canonicalization algorithm, a signature algorithm, and one or more references. The SignedInfo element may contain an optional ID attribute that will allow it to be referenced by other signatures and objects.
たSignedInfoの構造は、正規化アルゴリズム、署名アルゴリズム、および1つまたは複数の参照を含みます。 SignedInfoエレメントは、それが他の署名とオブジェクトによって参照されることを可能にするオプションのID属性を含んでいてもよいです。
SignedInfo does not include explicit signature or digest properties (such as calculation time, cryptographic device serial number, etc.). If an application needs to associate properties with the signature or digest, it may include such information in a SignatureProperties element within an Object element.
たSignedInfoは、明示的な署名を含むか、または（例えば、計算時間、暗号デバイスシリアルナンバー、等）の特性を消化しません。アプリケーションが署名付きプロパティを関連付けるまたは消化する必要がある場合、そのオブジェクト要素内SignatureProperties要素にそのような情報を含むことができます。
Schema Definition:
スキーマ定義：
<element name="SignedInfo" type="ds:SignedInfoType"/> <complexType name="SignedInfoType"> <sequence> <element ref="ds:CanonicalizationMethod"/> <element ref="ds:SignatureMethod"/> <element ref="ds:Reference" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType>
<要素名= "たSignedInfo" タイプ= "DS：SignedInfoType" /> <complexTypeの名前= "SignedInfoType"> <シーケンス> <要素REF = "DS：CanonicalizationMethodに" /> <要素REF = "DS：のSignatureMethod" /> <要素REF = "DS：リファレンス" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの>
DTD:
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 canonicalization algorithms.
CanonicalizationMethodに前の署名の計算を実行するSignedInfoエレメントに適用される正規化アルゴリズムを指定する必須元素です。この要素は、アルゴリズム識別子と実装要件（セクション6.1）に記載のアルゴリズムの一般的な構造を使用します。実装は、必要な正規化アルゴリズムをサポートしなければなりません。
Alternatives to the REQUIRED canonicalization algorithms (section 6.5), such as Canonical XML with Comments (section 6.5.1) or a minimal canonicalization (such as CRLF and charset normalization), may be explicitly specified but are NOT REQUIRED. Consequently, their use may not interoperate with other applications that do not support the specified algorithm (see XML Canonicalization and Syntax Constraint Considerations, section 7). Security issues may also arise in the treatment of entity processing and comments if non-XML aware canonicalization algorithms are not properly constrained (see section 8.2: Only What is "Seen" Should be Signed).
このようなコメント（セクション6.5.1）または（例えばCRLFと文字セットの正規化など）最小正規化と正規XMLとして必要な正規化アルゴリズム（セクション6.5）の代替は、明示的に指定することができるが、必要ではありません。したがって、その使用は、指定されたアルゴリズムを（セクション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 algorithms which process XML as nodes or characters:
SignedInfoエレメントを正規化方法に提示される方法は、その方法に依存しています。以下は、ノードや文字などのプロセスXMLアルゴリズムに適用されます。
* XML based canonicalization implementations MUST be provided with a [XPath] node-set originally formed from the document containing the SignedInfo and currently indicating the SignedInfo, its descendants, and the attribute and namespace nodes of SignedInfo and its descendant elements.
* XMLベースの正規化の実装は、当初たSignedInfoを含む、現在のSignedInfo、子孫、そしてたSignedInfoの属性と名前空間ノードおよびその子孫要素を示す文書から形成された[XPathの]ノード集合を備えていなければなりません。
* Text based canonicalization algorithms (such as CRLF and charset normalization) should be provided with the UTF-8 octets that represent the well-formed SignedInfo element, from the first character to the last character of the XML representation, inclusive. This includes the entire text of the start and end tags of the SignedInfo element as well as all descendant markup and character data (i.e., the text) between those tags. Use of text based canonicalization of SignedInfo is NOT RECOMMENDED.
（例えばCRLFと文字セットの正規化など）*テキストベースの正規化アルゴリズムは、包括的XML表現の最後の文字の最初の文字から整形SignedInfoエレメントを表すUTF-8オクテットを備えなければなりません。これは、SignedInfoエレメントの開始タグと終了タグのテキスト全体、ならびにこれらのタグの間のすべての子孫のマークアップと文字データ（すなわち、テキスト）を含みます。 SignedInfoのテキストベースの正規の使用は推奨されません。
We recommend applications that implement a text-based instead of XML-based canonicalization -- such as resource constrained apps -- generate canonicalized XML as their output serialization so as to mitigate interoperability and security concerns. For instance, such an implementation SHOULD (at least) generate standalone XML instances [XML].
そのようなリソースに制約のあるアプリケーションなど - - 私たちは、テキストベースの代わりにXMLベースの標準化のを実装するアプリケーションをお勧めします相互運用性とセキュリティの懸念を緩和するように、それらの出力シリアライズとして正規化されたXMLを生成します。例えば、そのような実装では、（少なくとも）スタンドアロンXMLインスタンス[XML]を生成する必要があります。
NOTE: The signature application must exercise great care in accepting and executing an arbitrary CanonicalizationMethod. For example, the canonicalization method could rewrite the URIs of the References being validated. Or, the method could massively transform SignedInfo so that validation would always succeed (i.e., converting it to a trivial signature with a known key over trivial data). Since CanonicalizationMethod is inside SignedInfo, in the resulting canonical form it could erase itself from SignedInfo or modify the SignedInfo element so that it appears that a different canonicalization function was used! Thus a Signature which appears to authenticate the desired data with the desired key, DigestMethod, and SignatureMethod, can be meaningless if a capricious CanonicalizationMethod is used.
注：署名アプリケーションは、任意のCanonicalizationMethodにを受け入れ、実行に細心の注意を払う必要があります。例えば、正規化方法は、検証される参照のURIを書き換えることができました。その検証は常に成功するように、または、この方法は、大規模な（些細なデータ以上の既知のキーと些細な署名に変換、すなわち）のSignedInfoを変換することができます。 CanonicalizationMethodにはのSignedInfoの内側にあるので、別の正規化機能を使用したと思われるように、結果の正規形でそれがたSignedInfoから自分自身を消去するか、SignedInfoエレメントを変更することができます！気まぐれCanonicalizationMethodには使用されている場合このようにして、所望のキー、DigestMethodとのSignatureMethodで所望のデータを認証するために表示される署名は、無意味であることができます。
Schema Definition:
スキーマ定義：
<element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/> <complexType name="CanonicalizationMethodType" mixed="true"> <sequence> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> <!-- (0,unbounded) elements from (1,1) namespace --> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType>
<要素名= "CanonicalizationMethodに" タイプ= "DS：CanonicalizationMethodType" /> <complexTypeの名= "CanonicalizationMethodType" 混合= "真"> <シーケンス> <名前空間= "##いずれか" のminOccurs = "0" のmaxOccurs = "無限"/> <！ - > </シーケンス> <属性名= - （1,1）の名前空間から（0、無制限）の要素" アルゴリズム」タイプ= "anyURIの" 使用= "必須" /> </ complexTypeの>
DTD:
DTD：
<!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY;)* > <!ATTLIST CanonicalizationMethod Algorithm CDATA #REQUIRED >
<！ELEMENT CanonicalizationMethodに（#PCDATA％の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.
SignatureMethodは、署名生成および検証のために使用されるアルゴリズムを指定する必須元素です。このアルゴリズムは、署名操作（例えば、ハッシュ、公開鍵アルゴリズム、MACが、パディング、等）に関与する全ての暗号化機能を識別する。アルゴリズムの識別子と実装要件：この要素は、6.1節で説明したアルゴリズムのために、ここで一般的な構造を使用しています。単一の識別子が存在するが、その識別子は、複数の異なる署名値を含むフォーマットを指定することができます。
Schema Definition:
スキーマ定義：
<element name="SignatureMethod" type="ds:SignatureMethodType"/> <complexType name="SignatureMethodType" mixed="true"> <sequence> <element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <!-- (0,unbounded) elements from (1,1) external namespace --> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType>
<要素名= "のSignatureMethod" タイプ= "DS：SignatureMethodType" /> <complexTypeの名前= "SignatureMethodType" 混合= "真"> <シーケンス> <要素名= "HMACOutputLength" のminOccurs = "0" タイプ=「DS：HMACOutputLengthType "/> <名前空間=" ##その他」のminOccurs = "0" のmaxOccurs = "無制限" /> <！ - （1,1）から（0、無限）素子外部の名前空間 - > </配列> <名前= "アルゴリズム" タイプ= "anyURIの" 使用属性= "必要" /> </ complexTypeの>
DTD:
DTD：
<!ELEMENT SignatureMethod (#PCDATA|HMACOutputLength %Method.ANY;)* > <!ATTLIST SignatureMethod Algorithm CDATA #REQUIRED >
<！ELEMENTのSignatureMethod（#PCDATA | HMACOutputLength％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.
リファレンスは、1回以上発生する可能性の要素です。これは、ダイジェストアルゴリズム、およびダイジェスト値、および必要に応じて署名されるオブジェクトの識別子、オブジェクトの種類、および/または前消化に適用される変換のリストを指定します。識別（URI）と変換消化コンテンツ（ダイジェスト方法に、すなわち、入力）が作成された方法について説明します。 Type属性は、参照されたデータの処理を容易にします。この仕様は、外部データに対して何ら要求をしないながら、例えば、アプリケーションは、リファレントがマニフェストであることを知らせることを望むことができます。オプションのID属性は、他の場所から参照することへの参照が可能になります。
Schema Definition:
スキーマ定義：
<element name="Reference" type="ds:ReferenceType"/> <complexType name="ReferenceType"> <sequence> <element ref="ds:Transforms" minOccurs="0"/> <element ref="ds:DigestMethod"/> <element ref="ds:DigestValue"/> </sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="URI" type="anyURI" use="optional"/> <attribute name="Type" type="anyURI" use="optional"/> </complexType>
<要素名= "リファレンス" タイプ= "DS：のReferenceType" /> <complexTypeの名= "するReferenceType"> <シーケンス> <要素REF = "DS：トランスフォーム" のminOccurs = "0" /> <要素REF =「DS： DigestMethod "/> <要素REF =" DS：DigestValue "/> </シーケンス> <属性名=" ID」タイプ= "ID" 使用= "オプション" /> <属性名= "URI" タイプ= "anyURIの" = "オプション" /> <属性名= "タイプ" タイプ= "anyURIの" 使用= "オプション" /> </ complexTypeの>は、使用します
DTD:
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 octets. 2. Any octets corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the octet value). 3. The original character is replaced by the resulting character sequence.
1.各禁止文字は、一個の以上のオクテットとして[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 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 node-sets" can include a node-set functional equivalent. Requirements over XPath processing can include application behaviors that are equivalent to the corresponding XPath behavior.
注：XPathが推奨されます。署名アプリケーションは、この仕様に準拠するために【のXPath]仕様に準拠する必要はありません。しかし、XPathデータモデルの定義（例えば、ノードセット）と構文は、署名生成の一部として、XML-AS-XML（代わりオクテット）を処理するもののための機能を説明するために、この文書内で使用されています。これらの機能を使用したいという方のために、準拠[XPathの]の実装では、これらの機能を実装する1つの方法ですが、それは必須ではありません。そのようなアプリケーションは、ノードセットに十分に機能的な置換を使用して、この仕様によって必要とされるのみXPath式の動作を実現することができました。しかし、簡単にするために、我々は一般的にすべての点でこの資格を含めずにXPathの用語を使用します。 「XPathノードセット」上の要件は、ノードセット機能的等価物を含むことができます。 XPathの処理上の要件は、対応するXPathの動作に相当するアプリケーションの動作を含むことができます。
The data-type of the result of URI dereferencing or subsequent Transforms is either an octet stream or an XPath node-set.
間接参照URIまたはその後の変換の結果のデータ型は、オクテットストリームまたはXPathノードセットのいずれかです。
The Transforms specified in this document are defined with respect to the input they require. The following is the default signature application behavior:
この文書で指定されたトランスフォームは、彼らが必要と入力に関して定義されています。以下は、デフォルトの署名アプリケーションの動作です：
* If the data object is an octet stream and the next transform requires a node-set, the signature application MUST attempt to parse the octets yielding the required node-set via [XML] well-formed processing. * If the data object is a node-set and the next transform requires octets, the signature application MUST attempt to convert the node-set to an octet stream using Canonical XML [XML-C14N].
*データオブジェクトがオクテットストリームと変換隣にあるノードセットを必要とする場合、署名アプリケーションが要求ノードセット[XML]を介して整形処理を生じるオクテットを解析しようとしなければなりません。 *データ・オブジェクトは、ノードセットと次変換である場合、署名アプリケーションは、カノニカルXML [XML-C14N]を使用して、オクテットストリームにノードセットを変換しようとしなければならない、オクテットを必要とします。
Users may specify alternative transforms that override these defaults in transitions between transforms that expect different inputs. The final octet stream contains the data octets being secured. The digest algorithm specified by DigestMethod is then applied to these data octets, resulting in the DigestValue.
ユーザーは、異なる入力を期待して、変換間の遷移にこれらのデフォルトを上書きする代替の変換を指定することもできます。最後のオクテットストリームは固定されているデータオクテットが含まれています。 DigestMethodによって指定されたダイジェストアルゴリズムは、DigestValueその結果、これらのデータオクテットに適用されます。
Unless the URI-Reference is a 'same-document' reference as defined in [URI, Section 4.2], the result of dereferencing the URI-Reference MUST be an octet stream. In particular, an XML document identified by URI is not parsed by the signature application unless the URI is a same-document reference or unless a transform that requires XML parsing is applied. (See Transforms (section 4.3.3.1).)
[URI、セクション4.2]で定義されるようにURIリファレンス「は同じ文書」参照でない限り、URI参照を間接参照の結果は、オクテットストリームでなければなりません。 URIは、同じ文書の参照であるか、または変換しない限り、それは、XMLの解析が適用される必要がない限り、特に、URIによって識別されるXML文書は、署名アプリケーションによって解析されていません。 （トランスフォーム（セクション4.3.3.1）を参照してください。）
When a fragment is preceded by an absolute or relative URI in the URI-Reference, the meaning of the fragment is defined by the resource's MIME type. Even for XML documents, URI dereferencing (including the fragment processing) might be done for the signature application by a proxy. Therefore, reference validation might fail if fragment processing is not performed in a standard way (as defined in the following section for same-document references). Consequently, we RECOMMEND that the URI attribute not include fragment identifiers and that such processing be specified as an additional XPath Transform.
フラグメントはURIリファレンスにおける絶対的または相対URIが先行する場合、断片の意味は、リソースのMIMEタイプによって定義されます。 XML文書の、（フラグメント処理を含む）間接参照URIは、プロキシによって署名アプリケーションのために行われるかもしれません。したがって、基準の検証は（同じ文書参照の次のセクションで定義されるような）フラグメント処理は、標準的な方法で実行されていない場合に失敗する可能性があります。したがって、我々は、URIがフラグメント識別子を含み、追加のXPathが変換等の処理が指定されることはない属性ことをお勧めします。
When a fragment is not preceded by a URI in the URI-Reference, XML signature applications MUST support the null URI and barename XPointer. We RECOMMEND support for the same-document XPointers '#xpointer(/)' and '#xpointer(id('ID'))' if the application also intends to support any canonicalization that preserves comments. (Otherwise URI="#foo" will automatically remove comments before the canonicalization can even be invoked.) All other support for XPointers is OPTIONAL, especially all support for barename and other
フラグメントはURI-リファレンスURIによって先行されていない場合、XML署名アプリケーションはヌルURIとbarenameのXPointerをサポートしなければなりません。私たちは、同じ文書のXPointers「#xpointer（/）」と「#xpointer（ID（」ID「））」のサポートを勧めのアプリケーションにもコメントを保持する任意の正規化を支援しようとする場合。 （正規化も呼び出すことができる前に、それ以外の場合はURI =「＃fooが」自動的コメントを削除します。）XPointersための他のすべてのサポートは、特にすべてのbarenameのサポートおよび他の任意であります
XPointers in external resources since the application may not have control over how the fragment is generated (leading to interoperability problems and validation failures).
アプリケーションから外部リソースでXPointerはフラグメントが（相互運用性の問題や検証の失敗につながる）が生成される方法を制御できない場合があります。
The following examples demonstrate what the URI attribute identifies and how it is dereferenced:
次の例では、URI属性を識別するもの、それが間接参照する方法を示します。
URI="http://example.com/bar.xml" Identifies the octets that represent the external resource 'http://example.com/bar.xml', that is probably an XML document given its file extension. URI="http://example.com/bar.xml#chapter1" Identifies the element with ID attribute value 'chapter1' of the external XML resource 'http://example.com/bar.xml', provided as an octet stream. Again, for the sake of interoperability, the element identified as 'chapter1' should be obtained using an XPath transform rather than a URI fragment (barename XPointer resolution in external resources is not REQUIRED in this specification). URI="" Identifies the node-set (minus any comment nodes) of the XML resource containing the signature URI="#chapter1" Identifies a node-set containing the element with ID attribute value 'chapter1' of the XML resource containing the signature. XML Signature (and its applications) modify this node-set to include the element plus all descendents including namespaces and attributes -- but not comments.
URI =「http://example.com/bar.xml」は、それはおそらく、そのファイルの拡張子指定されたXML文書で、外部リソース「http://example.com/bar.xml」を表すオクテットを識別します。 URIは=「http://example.com/bar.xml#chapter1」は、オクテットとして設けられ、外部XMLリソース「http://example.com/bar.xml」のID属性値「第1章」で要素を識別しますストリーム。再び、相互運用性のために、「第1章」として識別された要素は、XPathはURIフラグメントではなく、変換を用いて得られるはずである（外部リソースにbarename XPointerの分解能は、本明細書では必要とされません）。 URIは=「＃1第1章」署名を含むXMLリソースのID属性値「第1章」を持つ要素を含むノードセットを識別する「URI =署名を含むXMLリソースのノードセット（マイナス任意のコメント・ノード）を識別する」 。 XML署名（およびそのアプリケーション）の要素を加えた名前空間と属性を含むすべての子孫含めるには、このノード・セットを変更する - ではなく、コメントを。
Dereferencing a same-document reference MUST result in an XPath node-set suitable for use by Canonical XML [XML-C14N]. Specifically, dereferencing a null URI (URI="") MUST result in an XPath node-set that includes every non-comment node of the XML document containing the URI attribute. In a fragment URI, the characters after the number sign ('#') character conform to the XPointer syntax [Xptr]. When processing an XPointer, the application MUST behave as if the root node of the XML document containing the URI attribute were used to initialize the XPointer evaluation context. The application MUST behave as if the result of XPointer processing were a node-set derived from the resultant location-set as follows:
同じ文書の参照を逆参照すると、XPathノードセットカノニカルXML [XML-C14N]で使用するのに適しをもたらさなければなりません。具体的には、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)
1.廃棄ポイントノード2.すべてのXPathノードが（それがノード集合内にある場合）子とルートノードを置き換える範囲3内に完全または部分的なコンテンツを有する各範囲のノードを置き換えます
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
4. EプラスE（テキスト、コメント、PI、要素）とEとその子孫要素のすべての名前空間と属性ノードのすべての子孫を持つ任意の要素ノード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. It's necessary because when [XML-C14N] is passed a node-set, it processes the node-set as is: with or without comments. Only when it's called with an octet stream does it invoke its own XPath expressions (default or without comments). Therefore to retain the default behavior of stripping comments when passed a node-set, they are removed in the last step if the URI is not a full XPointer. To retain comments while selecting an element by an identifier ID, use the following full XPointer: URI='#xpointer(id('ID'))'. To retain comments while selecting the entire document, use the following full XPointer: URI='#xpointer(/)'. This XPointer contains a simple XPath expression that includes the root node, which the second to last step above replaces with all nodes of the parse tree (all descendants, plus all attributes, plus all namespaces nodes).
最後のステップは、ヌルのURI、barenameのXPointersと子のシーケンスXPointersのために行われます。またはコメントなし：[XML-C14N]はノードセットを渡されたとき、そのままノードは、設定され処理されるためには必要です。独自のXPath式（デフォルトまたはコメントなし）を呼び出しんオクテットストリームと呼ばれていた場合のみ。 URIがいっぱいのXPointerでない場合、したがってノードセットを通過した際に、コメントを剥離するデフォルトの動作を維持するために、彼らは最後の工程で除去されています。 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 Transforms may require explicit MIME type, charset (IANA registered "character set"), or other such information concerning the data they are receiving from an earlier Transform or the source data, although no Transform algorithm specified in this document needs such explicit information. Such data characteristics are provided as parameters to the Transform algorithm and should be described in the specification for the algorithm.
何この文書で指定されたアルゴリズムは、そのような明示的な情報を必要と変換するが、いくつかの変換は、明示的なMIMEタイプを必要とするかもしれない、文字セット、それらは以前変換またはソースデータから受信されたデータに関する、または他のそのような情報（IANAは、「文字セット」に登録されていません）。そのようなデータ特性は、変換アルゴリズムパラメータとして提供され、アルゴリズムの明細書に記載されるべきです。
Examples of transforms include but are not limited to base64 decoding [MIME], canonicalization [XML-C14N], XPath filtering [XPath], and XSLT [XSLT]. The generic definition of the Transform element also allows application-specific transform algorithms. For example, the transform could be a decompression routine given by a Java class appearing as a base64 encoded parameter to a Java Transform algorithm. However, applications should refrain from using application-specific transforms if they wish their signatures to be verifiable outside of their application domain. Transform Algorithms (section 6.6) define the list of standard transformations.
変換の例としては、BASE64のデコード[MIME]、正規[XML-C14N]、XPathのフィルタリング[たXPath]、およびXSLT [XSLT]に限定されません。変換要素の一般的な定義は、アプリケーション固有の変換アルゴリズムを可能にします。例えば、変換アルゴリズムを変換するJavaにbase64でエンコードされたパラメータとして登場するJavaクラスによって与えられた解凍ルーチンである可能性があります。彼らは自分のアプリケーションドメインの検証外であることを彼らの署名を希望する場合は、アプリケーションは、アプリケーション固有の変換の使用を控える必要があります。アルゴリズム（セクション6.6）の標準的な変換のリストを定義する変換。
Schema Definition:
スキーマ定義：
<element name="Transforms" type="ds:TransformsType"/> <complexType name="TransformsType"> <sequence> <element ref="ds:Transform" maxOccurs="unbounded"/> </sequence> </complexType>
<要素名= "トランスフォーム" タイプ= "DS：TransformsType" /> <complexTypeの名前= "TransformsType"> <シーケンス> <要素REF = "DS：変換" のmaxOccurs = "無制限" /> </配列> </ complexTypeの>
<element name="Transform" type="ds:TransformType"/> <complexType name="TransformType" mixed="true"> <choice minOccurs="0" maxOccurs="unbounded"> <any namespace="##other" processContents="lax"/> <!-- (1,1) elements from (0,unbounded) namespaces --> <element name="XPath" type="string"/> </choice> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType>
<要素名= "トランスフォーム" タイプ= "DS：TransformType" /> <complexTypeの名= "TransformType" 混合= "真の"> <選択肢のminOccurs = "0" のmaxOccurs = "無制限"> <任意の名前空間= "##他"のprocessContents =" 緩い "/> <！ - （0、無限の）名前空間から（1,1）の要素 - > <要素名=" XPathの」タイプ= "文字列" /> </選択> <属性名= "アルゴリズム" タイプ= "anyURIの" 使用= "必須" /> </ complexTypeの>
DTD:
DTD：
<!ELEMENT Transforms (Transform+)>
<！ELEMENT変換（+トランスフォーム）>
<!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* > <!ATTLIST Transform Algorithm CDATA #REQUIRED >
<！ELEMENT変換（#PCDATA |のXPath％のTransform.ANY;）*> <！ATTLIST変換アルゴリズムCDATA #REQUIRED>
<!ELEMENT XPath (#PCDATA) >
<！ELEMENTのXPath（#PCDATA）>
DigestMethod is a required element that identifies the digest algorithm to be applied to the signed object. This element uses the general structure here for algorithms specified in Algorithm Identifiers and Implementation Requirements (section 6.1).
DigestMethodダイジェストアルゴリズムを識別する必須要素は、署名されたオブジェクトに適用されます。この要素は、アルゴリズムの識別子と実装要件（6.1節）に指定されたアルゴリズムのために、ここで一般的な構造を使用しています。
If the result of the URI dereference and application of Transforms is an XPath node-set (or sufficiently functional replacement implemented by the application) then it must be converted as described in the Reference Processing Model (section 4.3.3.2). If the result of URI dereference and application of transforms is an octet stream, then no conversion occurs (comments might be present if the Canonical XML with Comments was specified in the Transforms). The digest algorithm is applied to the data octets of the resulting octet stream.
変換のURIを逆参照とアプリケーションの結果は、XPathノードセット（またはアプリケーションによって実装十分に機能的置換）である場合に参照処理モデル（セクション4.3.3.2）で説明したように、それを変換しなければなりません。 URIの間接参照と変換の適用の結果は、オクテットストリームである場合、変換は（コメントカノニカルXMLトランスフォームで指定された場合にコメントが存在するかもしれない）が発生しません。ダイジェストアルゴリズムは、得られたオクテットストリームのデータオクテットに適用されます。
Schema Definition:
スキーマ定義：
<element name="DigestMethod" type="ds:DigestMethodType"/> <complexType name="DigestMethodType" mixed="true"> <sequence> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType>
<要素名= "DigestMethod" タイプ= "DS：DigestMethodType" /> <complexTypeの名前= "DigestMethodType" 混合= "真"> <シーケンス> <名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0 "のmaxOccurs =" 無制限 "/> </シーケンス> <属性名=" アルゴリズム」タイプ= "anyURIの" 使用= "必須" /> </ complexTypeの>
DTD:
DTD：
<!ELEMENT DigestMethod (#PCDATA %Method.ANY;)* > <!ATTLIST DigestMethod Algorithm CDATA #REQUIRED >
<！ELEMENT DigestMethod（#PCDATA％の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].
DigestValueダイジェストのエンコードされた値を含む要素です。ダイジェストは常にBASE64 [MIME]を使用して符号化されます。
Schema Definition:
スキーマ定義：
<element name="DigestValue" type="ds:DigestValueType"/> <simpleType name="DigestValueType"> <restriction base="base64Binary"/> </simpleType>
<要素名= "DigestValue" タイプ= "DS：DigestValueType" /> <単純名= "DigestValueType"> <制限ベース= "base64Binaryの" /> </ simpleTypeの>
DTD:
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 extend those types or all together replace them with their own key identification and exchange semantics using the XML namespace facility. [XML-ns] However, questions of trust of such key information (e.g., its authenticity or strength) are out of scope of this specification and left to the application.
KeyInfoは、署名を検証するために必要な鍵を取得するために受信者（複数可）を可能にする任意の要素です。 KeyInfoには、このような帯域内鍵配布または鍵合意データなどのキー、名前、証明書および他の公開鍵管理情報を含むことができます。この仕様は、いくつかの簡単なタイプを定義しますが、アプリケーションは、これらの型を拡張するか、すべて一緒にXML名前空間機能を使用して、独自のキー識別および交換のセマンティクスとそれらを置き換えることができます。 [XML-NSは、しかし、そのようなキー情報（例えば、その真正性または強度）の信頼の問題は、本明細書の範囲外であり、アプリケーションに任さ。
If KeyInfo is omitted, the recipient is expected to be able to identify the key based on application context. Multiple declarations within KeyInfo refer to the same key. While applications may define and use any mechanism they choose through inclusion of elements from a different namespace, compliant versions MUST implement KeyValue (section 4.4.2) and SHOULD implement RetrievalMethod (section 4.4.3).
KeyInfoが省略された場合、受信者は、アプリケーションのコンテキストに基づいてキーを識別することができると期待されます。 KeyInfo内の複数の宣言が同じキーを参照してください。アプリケーションが別の名前空間からの要素を含めることによって、彼らが選択した任意のメカニズムを定義して使用することができるが、コンプライアントバージョンはです。KeyValue（セクション4.4.2）を実装しなければならないとRetrievalMethod（セクション4.4.3）を実装する必要があります。
The schema/DTD specifications of many of KeyInfo's children (e.g., PGPData, SPKIData, X509Data) permit their content to be extended/complemented with elements from another namespace. This may be done only if it is safe to ignore these extension elements while claiming support for the types defined in this specification. Otherwise, external elements, including alternative structures to those defined by this specification, MUST be a child of KeyInfo. For example, should a complete XML-PGP standard be defined, its root element MUST be a child of KeyInfo. (Of course, new structures from external namespaces can incorporate elements from the &dsig; namespace via features of the type definition language. For instance, they can create a DTD that mixes their own and dsig qualified elements, or a schema that permits, includes, imports, or derives new types based on &dsig; elements.)
KeyInfoの子供たちの多くのスキーマ/ DTDの仕様（例えば、PGPData、SPKIData、X509Data）は、その内容が別の名前空間からの要素を補完/拡張することを可能にします。この仕様で定義されたタイプのサポートを主張しながら、これらの拡張要素を無視しても安全である場合にのみ行うことができます。そうでない場合は、この仕様で定義されたものと別の構造を含む外部要素は、KeyInfoのの子でなければなりません。完全なXML-PGPの標準を定義する必要があります例えば、そのルート要素は、KeyInfoのの子でなければなりません。タイプ定義言語の特徴を介して、名前空間例えば、彼らは自分とDSIG資格要素、または許可スキーマをミックスDTDを作成することができ、含み;（もちろん、外部の名前空間から新しい構造は、＆DSIGからの要素を組み込むことができます。 、輸入は、または＆DSIGに基づいて、新しいタイプの派生;要素）
The following list summarizes the KeyInfo types that are allocated to an identifier in the &dsig; namespace; these can be used within the RetrievalMethod Type attribute to describe a remote KeyInfo structure.
以下のリストは、＆DSIGにおける識別子に割り当てられているキー情報の種類をまとめたもの。名前空間;これらは、リモートキー情報構造を記述するためにRetrievalMethod Type属性内で使用することができます。
* http://www.w3.org/2000/09/xmldsig#DSAKeyValue * http://www.w3.org/2000/09/xmldsig#RSAKeyValue * http://www.w3.org/2000/09/xmldsig#X509Data * http://www.w3.org/2000/09/xmldsig#PGPData * http://www.w3.org/2000/09/xmldsig#SPKIData * http://www.w3.org/2000/09/xmldsig#MgmtData
* http://www.w3.org/2000/09/xmldsig#DSAKeyValue * http://www.w3.org/2000/09/xmldsig#RSAKeyValue * http://www.w3.org/2000/09/xmldsig#X509Data * http://www.w3.org/2000/09/xmldsig#PGPData * http://www.w3.org/2000/09/xmldsig#SPKIData * http://www.w3.org/2000/09/xmldsig#MgmtData
In addition to the types above for which we define an XML structure, we specify one additional type to indicate a binary (ASN.1 DER) X.509 Certificate.
我々は、XML構造を定義するための上記のタイプに加えて、我々は、バイナリ（ASN.1のDER）X.509証明書を示すために1つの追加のタイプを指定します。
* http://www.w3.org/2000/09/xmldsig#rawX509Certificate
＊ ｈっｔｐ：／／ｗっｗ。ｗ３。おｒｇ／２０００／０９／ｘｍｌｄしｇ＃らｗＸ５０９せｒちふぃかて
Schema Definition:
スキーマ定義：
<element name="KeyInfo" type="ds:KeyInfoType"/> <complexType name="KeyInfoType" mixed="true"> <choice maxOccurs="unbounded"> <element ref="ds:KeyName"/> <element ref="ds:KeyValue"/> <element ref="ds:RetrievalMethod"/> <element ref="ds:X509Data"/> <element ref="ds:PGPData"/> <element ref="ds:SPKIData"/> <element ref="ds:MgmtData"/> <any processContents="lax" namespace="##other"/> <!-- (1,1) elements from (0,unbounded) namespaces --> </choice> <attribute name="Id" type="ID" use="optional"/> </complexType>
<要素名= "KeyInfoの" タイプ= "DS：KeyInfoType" /> <complexTypeの名= "KeyInfoType" 混合= "真の"> <選択肢のmaxOccurs = "無制限"> <要素REF = "DS：キー名" /> <要素REF = "DS：です。KeyValue" /> <要素REF = "DS：RetrievalMethod" /> <要素REF = "DS：X509Data" /> <要素REF = "DS：PGPData" /> <要素REF =「DS：SPKIData "/> <要素REF =" DS：！MgmtData "/> <どんなのprocessContents =" 緩い」名前空間= "##他の" /> < - （0、無限の）名前空間から（1,1）の要素 - > </選択> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの>
DTD:
DTD：
<!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod| X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* > <!ATTLIST KeyInfo Id ID #IMPLIED >
<！ELEMENTのKeyInfo（#PCDATA |キー名|です。KeyValue | RetrievalMethod | X509Data | PGPData | SPKIData | MgmtData％KeyInfo.ANY;）*> <！ATTLISTのKeyInfo IdをID #IMPLIED>
The KeyName element contains a string value (in which white space is significant) which may be used by the signer to communicate a key identifier to the recipient. Typically, KeyName contains an identifier related to the key pair used to sign the message, but it may contain other protocol-related information that indirectly identifies a key pair. (Common uses of KeyName include simple string names for keys, a key index, a distinguished name (DN), an email address, etc.)
KEYNAME要素は、受信者にキー識別子を通信するために署名者によって使用されてもよい（ホワイトスペースは重要である）は、文字列値を含みます。典型的には、キー名は、メッセージに署名するために使用される鍵ペアに関連する識別子を含むが、それは間接的に鍵のペアを特定する他のプロトコルに関連する情報を含むことができます。 （キー名の一般的な用途は、キーの単純な文字列名などのキーインデックス、識別名（DN）、電子メールアドレスが含まれます）
Schema Definition:
スキーマ定義：
<element name="KeyName" type="string"/>
<要素名=「キー名」タイプ=「文字列」/>
DTD:
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). The KeyValue element may include externally defined public key values represented as PCDATA or element types from an external namespace.
です。KeyValue要素は、署名を検証するのに有用であり得る単一の公開鍵を含みます。 DSA（REQUIRED）とRSAを定義するための構造化されたフォーマットは、公開鍵は、署名アルゴリズム（セクション6.4）で定義されている（推奨します）。です。KeyValue要素は、外部の名前空間の外部で定義された公開鍵PCDATAとして表す値や要素タイプを含むことができます。
Schema Definition:
スキーマ定義：
<element name="KeyValue" type="ds:KeyValueType"/> <complexType name="KeyValueType" mixed="true"> <choice> <element ref="ds:DSAKeyValue"/> <element ref="ds:RSAKeyValue"/> <any namespace="##other" processContents="lax"/> </choice> </complexType>
<要素名= "です。KeyValue" タイプ= "DS：KeyValueType" /> <complexTypeの名= "KeyValueType" 混合= "真の"> <選択> <要素REF = "DS：DSAKeyValue" /> <要素REF =「DS： RSAKeyValue "/> <任意の名前空間=" ##他」のprocessContents = "緩い" /> </選択> </ complexTypeの>
DTD:
DTD：
<!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY;)* >
<！ELEMENTです。KeyValue（#PCDATA | DSAKeyValue | RSAKeyValue％KeyValue.ANY;）*>
Identifier Type="http://www.w3.org/2000/09/xmldsig#DSAKeyValue" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ=「http://www.w3.org/2000/09/xmldsig#DSAKeyValue」（これは、参照先の種類を識別するためにRetrievalMethodまたは参照要素内で使用することができます）
DSA keys and the DSA signature algorithm are specified in [DSS]. DSA public key values can have the following fields:
DSAキーとDSA署名アルゴリズムは、[DSS]で指定されています。 DSA公開鍵の値は、次のフィールドを持つことができます。
P a prime modulus meeting the [DSS] requirements Q an integer in the range 2**159 < Q < 2**160 which is a prime divisor of P-1 G an integer with certain properties with respect to P and Q Y G**X mod P (where X is part of the private key and not made public) J (P - 1) / Q seed a DSA prime generation seed pgenCounter a DSA prime generation counter
P素数モジュラス会議[DSS]要件Q PとQYGに対して一定の特性を有する整数P-1 Gの素数除数範囲2 ** 159 <Q <2 ** 160の整数** （Xは、公開され、秘密鍵としないの一部である）X MOD P J（P - 1）/ Q種子pgenCounter DSA素数生成カウンタDSA素数生成種
Parameter J is available for inclusion solely for efficiency as it is calculatable from P and Q. Parameters seed and pgenCounter are used in the DSA prime number generation algorithm specified in [DSS]. As such, they are optional, but must either both be present or both be absent. This prime generation algorithm is designed to provide assurance that a weak prime is not being used and it yields a P and Q value. Parameters P, Q, and G can be public and common to a group of users. They might be known from application context. As such, they are optional but P and Q must either both appear or both be absent. If all of P, Q, seed, and pgenCounter are present, implementations are not required to check if they are consistent and are free to use either P and Q or seed and pgenCounter. All parameters are encoded as base64 [MIME] values.
それはPから計算可能であり、Q.パラメータシードとpgenCounterが[DSS]で指定されたDSA素数生成アルゴリズムで使用されるパラメータJは、単に効率のために含めるのに利用可能です。そのようなものとして、それらは任意であるが、いずれかの両方が存在すること、またはその両方に存在してはなりません。この素数生成アルゴリズムが弱い首相が使用されていないことを保証を提供するために設計されており、それがPとQ値が得られています。パラメータは、P、Q、およびGは、公共およびユーザのグループに共通することができます。彼らは、アプリケーションのコンテキストから知られている可能性があります。そのため、彼らはオプションですが、PとQの両方が表示される必要がありますいずれかまたは両方が存在しないこと。 P、Q、種子、およびpgenCounterの全てが存在する場合、実装は、一貫性があり、PとQまたは種子とpgenCounterのいずれかを使用して自由であるかどうかを確認する必要はありません。全てのパラメータは、BASE64 [MIME]値として符号化されます。
Arbitrary-length integers (e.g., "bignums" such as RSA moduli) are represented in XML as octet strings as defined by the ds:CryptoBinary type.
CryptoBinaryタイプ：任意の長さの整数（例えば、RSAモジュラスのような「bignums」）は、DSにより定義されるオクテットストリングとしてXMLで表現されています。
Schema Definition:
スキーマ定義：
<element name="DSAKeyValue" type="ds:DSAKeyValueType"/> <complexType name="DSAKeyValueType"> <sequence> <sequence minOccurs="0"> <element name="P" type="ds:CryptoBinary"/> <element name="Q" type="ds:CryptoBinary"/> </sequence> <element name="G" type="ds:CryptoBinary" minOccurs="0"/> <element name="Y" type="ds:CryptoBinary"/> <element name="J" type="ds:CryptoBinary" minOccurs="0"/> <sequence minOccurs="0"> <element name="Seed" type="ds:CryptoBinary"/> <element name="PgenCounter" type="ds:CryptoBinary"/> </sequence> </sequence> </complexType>
<要素名= "DSAKeyValue" タイプ= "DS：DSAKeyValueType" /> <complexTypeの名前= "DSAKeyValueType"> <シーケンス> <配列のminOccurs = "0"> <要素名= "P" タイプ= "DS：CryptoBinary" / > <要素名= "Q" タイプ= "DS：CryptoBinary" /> </配列> <要素名= "G" タイプ= "DS：CryptoBinary" のminOccurs = "0" /> <要素名= "Y" 型= "DS：CryptoBinary" /> <要素名= "J" タイプ= "DS：CryptoBinary" のminOccurs = "0" /> <配列のminOccurs = "0"> <要素名= "シード" タイプ=「DS：CryptoBinary "/> <要素名=" PgenCounter」タイプ= "DS：CryptoBinary" /> </シーケンス> </シーケンス> </ complexTypeの>
DTD Definition:
DTDの定義：
<!ELEMENT DSAKeyValue ((P, Q)?, G?, Y, J?, (Seed, PgenCounter)?) > <!ELEMENT P (#PCDATA) > <!ELEMENT Q (#PCDATA) > <!ELEMENT G (#PCDATA) > <!ELEMENT Y (#PCDATA) > <!ELEMENT J (#PCDATA) > <!ELEMENT Seed (#PCDATA) > <!ELEMENT PgenCounter (#PCDATA) >
<！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 Type="http://www.w3.org/2000/09/xmldsig#RSAKeyValue" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ=「http://www.w3.org/2000/09/xmldsig#RSAKeyValue」（これは、参照先の種類を識別するためにRetrievalMethodまたは参照要素内で使用することができます）
RSA key values have two fields: Modulus and Exponent.
モジュラスおよび指数：RSAキーの値は、二つのフィールドを持っています。
<RSAKeyValue> <Modulus> xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRg BUwUlV5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U= </Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue>
<RSAKeyValue> <弾性率> xA7SEU + e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRg BUwUlV5foK5hhmbktQhyNdy / 6LpQRhDUDsTvK + g9Ucj47es9AQJ3U = </弾性率> <指数> AQAB </指数> </ RSAKeyValue>
Arbitrary-length integers (e.g., "bignums" such as RSA moduli) are represented in XML as octet strings as defined by the ds:CryptoBinary type.
CryptoBinaryタイプ：任意の長さの整数（例えば、RSAモジュラスのような「bignums」）は、DSにより定義されるオクテットストリングとしてXMLで表現されています。
Schema Definition:
スキーマ定義：
<element name="RSAKeyValue" type="ds:RSAKeyValueType"/> <complexType name="RSAKeyValueType"> <sequence> <element name="Modulus" type="ds:CryptoBinary"/> <element name="Exponent" type="ds:CryptoBinary"/> </sequence> </complexType>
<要素名= "RSAKeyValue" タイプ= "DS：RSAKeyValueType" /> <complexTypeの名前= "RSAKeyValueType"> <シーケンス> <要素名= "モジュラス" タイプ= "DS：CryptoBinary" /> <要素名= "指数"タイプ= "DS：CryptoBinary" /> </シーケンス> </ complexTypeの>
DTD Definition:
DTDの定義：
<!ELEMENT RSAKeyValue (Modulus, Exponent) > <!ELEMENT Modulus (#PCDATA) > <!ELEMENT Exponent (#PCDATA) >
<！ELEMENT RSAKeyValue（モジュラス、指数）> <！ELEMENTモジュラス（#PCDATA）> <！ELEMENT指数（#PCDATA）>
A RetrievalMethod element within KeyInfo is used to convey a reference to KeyInfo information that is stored at another location. For example, several signatures in a document might use a key verified by an X.509v3 certificate chain appearing once in the document or remotely outside the document; each signature's KeyInfo can reference this chain using a single RetrievalMethod element instead of including the entire chain with a sequence of X509Certificate elements.
KeyInfo内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.
RetrievalMethodは、そこにはDigestMethodまたはDigestValue子要素ではないとURIの存在が必須であること以外は、参考のURI（セクション4.3.3.1）およびリファレンス処理モデルと同じ構文とデリファレンス動作（セクション4.3.3.2）を使用しています。
Type is an optional identifier for the type of data to be retrieved. The result of dereferencing a RetrievalMethod Reference for all KeyInfo types defined by this specification (section 4.4) with a corresponding XML structure is an XML element or document with that element as the root. The rawX509Certificate KeyInfo (for which there is no XML structure) returns a binary X509 certificate.
タイプは、検索されるべきデータのタイプの任意の識別子です。対応するXML構造を有する、本明細書（セクション4.4）で定義されたすべてのキー情報タイプのRetrievalMethodリファレンスを間接参照の結果は、ルートとしてその要素を有するXML要素または文書です。 rawX509CertificateのKeyInfoは（そのためないXML構造が存在しない）バイナリX509証明書を返します。
Schema Definition:
スキーマ定義：
<element name="RetrievalMethod" type="ds:RetrievalMethodType"/> <complexType name="RetrievalMethodType"> <sequence> <element ref="ds:Transforms" minOccurs="0"/> </sequence> <attribute name="URI" type="anyURI"/> <attribute name="Type" type="anyURI" use="optional"/> </complexType>
<要素名= "RetrievalMethod" タイプ= "DS：RetrievalMethodType" /> <complexTypeの名= "RetrievalMethodType"> <シーケンス> <要素REF = "DS：トランスフォーム" のminOccurs = "0" /> </シーケンス> <属性名= "URI" タイプ= "anyURIの" /> <属性名= "タイプ" タイプ= "anyURIの" 使用= "オプション" /> </ complexTypeの>
DTD:
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 a revocation list). The content of X509Data is:
KeyInfo内X509Data要素は、キーまたはX509証明書（または証明書の識別子または失効リスト）の1つの以上の識別子が含まれています。 X509Dataの内容は次のとおりです。
1. At least one element, from the following set of element types; any of these may appear together or more than once if (if and only if) each instance describes or is related to the same certificate: 2. o The X509IssuerSerial element, which contains an X.509 issuer distinguished name/serial number pair that SHOULD be compliant with RFC 2253 [LDAP-DN], o The X509SubjectName element, which contains an X.509 subject distinguished name that SHOULD be compliant with RFC 2253 [LDAP-DN], o The X509SKI element, which contains the base64 encoded plain (i.e., non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier extension. o The X509Certificate element, which contains a base64-encoded [X509v3] certificate, and o Elements from an external namespace which accompanies/complements any of the elements above. o The X509CRL element, which contains a base64-encoded certificate revocation list (CRL) [X509v3].
1.少なくとも一種の元素、要素型の次のセットから、各インスタンスは、説明し又は同一の証明書に関連している（そして場合だけ）場合は、これらのいずれかは、一緒に、または複数回表示されることがあります。2. X.509発行者識別名/ SHOULDシリアル番号のペアが含まX509IssuerSerial要素、O- BASE64符号化された平野が含まX509SKI要素、（O、RFC 2253 [LDAP-DN]に準拠するべきであるX.509サブジェクト識別名が含まれているX509SubjectName素子、O、RFC 2253 [LDAP-DN]に準拠してすなわち、非DERでエンコードされた）X509 V.3 SubjectKeyIdentifier拡張の値。 base64エンコード[書X509v3]証明書、及び付随/上記要素のいずれかを補完する外部の名前空間からのO元素が含まれているのX509Certificate要素、O。 [書X509v3] Base64でエンコードされた証明書失効リスト（CRL）を含有X509CRL素子、O。
Any X509IssuerSerial, X509SKI, and X509SubjectName elements that appear MUST refer to the certificate or certificates containing the validation key. All such elements that refer to a particular individual certificate MUST be grouped inside a single X509Data element and if the certificate to which they refer appears, it MUST also be in that X509Data element.
表示されるすべてのX509IssuerSerial、X509SKI、およびX509SubjectName要素は、証明書または検証鍵を含む証明書を参照する必要があります。特定の個人証明書を参照するすべてのそのような要素は、単一X509Data要素内にグループ化する必要があり、それらは参照する証明書が表示された場合、それはまた、そのX509Data要素でなければなりません。
Any X509IssuerSerial, X509SKI, and X509SubjectName elements that relate to the same key but different certificates MUST be grouped within a single KeyInfo but MAY occur in multiple X509Data elements.
同じキーが、異なる証明書に関連する任意X509IssuerSerial、X509SKI、及びX509SubjectName要素は、単一のKeyInfo内でグループ化されなければならないが、複数X509Data要素で起こり得ます。
All certificates appearing in an X509Data element MUST relate to the validation key by either containing it or being part of a certification chain that terminates in a certificate containing the validation key.
X509Data要素に現れるすべての証明書は、それを含むか、検証鍵を含む証明書で終わる証明書チェーンの一部であることのいずれかによって検証鍵に関連しなければなりません。
No ordering is implied by the above constraints. The comments in the following instance demonstrate these constraints:
何順序は上記の制約によって暗示されていません。以下のインスタンス内のコメントは、これらの制約を示します。
<KeyInfo> <X509Data> <!-- two pointers to certificate-A --> <X509IssuerSerial> <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM, L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName> <X509SerialNumber>12345678</X509SerialNumber> </X509IssuerSerial> <X509SKI>31d97bd7</X509SKI> </X509Data> <X509Data><!-- single pointer to certificate-B --> <X509SubjectName>Subject of Certificate B</X509SubjectName> </X509Data> <X509Data> <!-- certificate chain --> <!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4--> <X509Certificate>MIICXTCCA..</X509Certificate> <!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --> <X509Certificate>MIICPzCCA...</X509Certificate> <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US --> <X509Certificate>MIICSTCCA...</X509Certificate> </X509Data> </KeyInfo>
<の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> <X509Data> <！ - 証明書チェーン - > <！ - 署名者の証明書、発行者CN = arbolCA、OU = FVT、O = IBM、C = US、シリアル4-- > <X509Certificateに> MIICXTCCA .. </ X509Certificateに> <！ - 中間証明書件名CN = arbolCA、OU = FVT、O = IBM、C = USの発行者CN = tootiseCA、OU = FVT、O =ブリッジポイントは、Cは、米国を= - - > <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 and CRLs can occur within an X509Data element and multiple X509Data elements can occur in a KeyInfo. Whenever multiple certificates occur in an X509Data element, at least one such certificate must contain the public key which verifies the signature.
証明書やCRLのの「袋」エンコードPKCS＃7には直接の規定はありません、注意してください。しかし、証明書およびCRLのセットは、のKeyInfoで起こり得るX509Data要素と複数X509Data要素内で発生することができます。複数の証明書はX509Data要素で発生するたびに、少なくとも一つのそのような証明書は、署名を検証する公開鍵を含んでいなければなりません。
Also, strings in DNames (X509IssuerSerial,X509SubjectName, and KeyNameif appropriate) should be encoded as follows:
次のようにも、DNames（X509IssuerSerial、X509SubjectName、及びKeyNameif適切な）内の文字列は、符号化されるべきです。
* Consider the string as consisting of Unicode characters. * Escape occurrences of the following special characters by prefixing it with the "\" character: a "#" character occurring at the beginning of the string or one of the characters ",", "+", """, "\", "<", ">" or ";" * Escape all occurrences of ASCII control characters (Unicode range \x00 - \x 1f) by replacing them with "\" followed by a two digit hex number showing its Unicode number. * Escape any trailing white space by replacing "\ " with "\20". * Since a XML document logically consists of characters, not octets, the resulting Unicode string is finally encoded according to the character encoding used for producing the physical representation of the XML document.
* Unicode文字から成るものとして文字列を考えてみましょう。 *「\」の文字とそれを付けることによって、次の特殊文字の出現をエスケープ：「＃」文字列の先頭に発生する文字または文字の一つ」、 『『+』、『』』、 『\』 、「<」、「>」または「;」。* ASCII制御文字のすべてのオカレンスの脱出 - そのUnicodeの数を示す2桁の16進数に続く「\」に置き換えることにより、（Unicodeの範囲\ X00 \ X 1F）を* 「\ 20」と「\」を置き換えることにより、任意の末尾の空白をエスケープします。* XML文書は、論理的に文字ではなく、オクテットで構成されているので、結果のUnicode文字列が最終的にXMLの物理的な表現を生成するために使用される文字コードに従って符号化されます資料。
Schema Definition:
スキーマ定義：
<element name="X509Data" type="ds:X509DataType"/> <complexType name="X509DataType"> <sequence maxOccurs="unbounded"> <choice> <element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/> <element name="X509SKI" type="base64Binary"/> <element name="X509SubjectName" type="string"/> <element name="X509Certificate" type="base64Binary"/> <element name="X509CRL" type="base64Binary"/> <any namespace="##other" processContents="lax"/> </choice> </sequence> </complexType> <complexType name="X509IssuerSerialType"> <sequence> <element name="X509IssuerName" type="string"/> <element name="X509SerialNumber" type="integer"/> </sequence> </complexType>
<要素名= "X509Data" タイプ= "DS：X509DataType" /> <complexTypeの名= "X509DataType"> <シーケンスのmaxOccurs = "無制限"> <選択> <要素名= "X509IssuerSerial" タイプ= "DS：X509IssuerSerialType" / > <要素名= "X509SKI" タイプ= "base64Binaryの" /> <要素名= "X509SubjectName" タイプ= "文字列" /> <要素名= "X509Certificateの" タイプ= "base64Binaryの" /> <要素名= "X509CRL" "##その他" = = "base64Binaryの" /> <任意の名前空間を入力のprocessContents = "緩い" /> </選択> </シーケンス> </ complexTypeの> <complexTypeの名前= "X509IssuerSerialType"> <シーケンス> <要素名= "X509IssuerName" タイプ= "文字列" /> <要素名= "X509SerialNumber" タイプ= "整数" /> </配列> </ complexTypeの>
DTD:
DTD：
<!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName | X509Certificate | X509CRL)+ %X509.ANY;)> <!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) > <!ELEMENT X509IssuerName (#PCDATA) > <!ELEMENT X509SubjectName (#PCDATA) > <!ELEMENT X509SerialNumber (#PCDATA) > <!ELEMENT X509SKI (#PCDATA) > <!ELEMENT X509Certificate (#PCDATA) > <!ELEMENT X509CRL (#PCDATA) >
<！ELEMENT X509Data（（X509IssuerSerial | X509SKI | X509SubjectName |のX509Certificate | X509CRL）+％X509.ANY;）> <！ELEMENT X509IssuerSerial（X509IssuerName、X509SerialNumber）> <！ELEMENT X509IssuerName（#PCDATA）> <！ELEMENT X509SubjectName（#PCDATA ）> <！ELEMENT X509SerialNumber（#PCDATA）> <！ELEMENT X509SKI（#PCDATA）> <！ELEMENTのX509Certificate（#PCDATA）> <！ELEMENT X509CRL（#PCDATA）>
<!-- Note, this DTD and schema permit X509Data to be empty; this is precluded by the text in KeyInfo Element (section 4.4) which states that at least one element from the dsig namespace should be present in the PGP, SPKI, and X509 structures. This is easily expressed for the other key types, but not for X509Data because of its rich structure. -->
<！ - 注意、このDTDやスキーマの許可X509Data空に。これはDSIG名前空間から少なくとも一つの元素がPGP、SPKI、およびX509構造で存在すべきであると述べているのKeyInfo要素内のテキスト（セクション4.4）によって排除されます。これは簡単ではなく、X509Dataのために、その豊富な構造の、他のキータイプのために表現されています。 - >
Identifier Type="http://www.w3.org/2000/09/xmldsig#PGPData" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ=「http://www.w3.org/2000/09/xmldsig#PGPData」（これは、参照先の種類を識別するために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 base64Binary sequence containing a standard PGP public key identifier as defined in [PGP, section 11.2]. The PGPKeyPacket contains a base64-encoded Key Material Packet as defined in [PGP, section 5.5]. These children element types can be complemented/extended by siblings from an external namespace within PGPData, or PGPData can be replaced all together with an alternative PGP XML structure as a child of KeyInfo. PGPData must contain one PGPKeyID and/or one PGPKeyPacket and 0 or more elements from an external namespace.
KeyInfo内PGPData要素は、キーの公開鍵ペアおよび署名をPGPに関連する情報を伝えるために使用されます。 PGPKeyIDの値は、[PGP、セクション11.2]で定義されるような標準PGP公開鍵識別子を含むbase64Binaryの配列です。 [PGP、セクション5.5]で定義されるようPGPKeyPacketはbase64で符号化された鍵素材パケットを含んでいます。これらの子供の要素タイプはPGPData内の外部ネームスペースからの兄弟によって拡張/補完することができる、またはPGPDataはのKeyInfoの子として代替PGPのXML構造に一斉に置き換えることができます。 PGPDataは1 PGPKeyIDおよび/または1 PGPKeyPacketおよび外部ネームスペースから0以上の要素が含まれている必要があります。
Schema Definition:
スキーマ定義：
<element name="PGPData" type="ds:PGPDataType"/> <complexType name="PGPDataType"> <choice> <sequence> <element name="PGPKeyID" type="base64Binary"/> <element name="PGPKeyPacket" type="base64Binary" minOccurs="0"/> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <sequence> <element name="PGPKeyPacket" type="base64Binary"/> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> </choice> </complexType>
<要素名= "PGPData" タイプ= "DS：PGPDataType" /> <complexTypeの名= "PGPDataType"> <選択> <シーケンス> <要素名= "PGPKeyID" タイプ= "base64Binaryの" /> <要素名= "PGPKeyPacket "TYPE =" base64Binaryの」のminOccurs = "0" /> <名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </配列> <シーケンス> <要素名= "PGPKeyPacket" タイプ= "base64Binaryの" /> <任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </シーケンス> </選択> </ complexTypeの>
DTD:
DTD：
<!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket) %PGPData.ANY;) > <!ELEMENT PGPKeyPacket (#PCDATA) > <!ELEMENT PGPKeyID (#PCDATA) >
<！ELEMENT PGPData（（PGPKeyID、PGPKeyPacket）|（PGPKeyPacket）％のPGPData.ANY;？）> <！ELEMENT PGPKeyPacket（#PCDATA）> <！ELEMENT PGPKeyID（#PCDATA）>
Identifier Type="http://www.w3.org/2000/09/xmldsig#SPKIData" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ=「http://www.w3.org/2000/09/xmldsig#SPKIData」（これは、参照先の種類を識別するためにRetrievalMethodまたは参照要素内で使用することができます）
The SPKIData element within KeyInfo is used to convey information related to SPKI public key pairs, certificates and other SPKI data. SPKISexp is the base64 encoding of a SPKI canonical S-expression. SPKIData must have at least one SPKISexp; SPKISexp can be complemented/extended by siblings from an external namespace within SPKIData, or SPKIData can be entirely replaced with an alternative SPKI XML structure as a child of KeyInfo.
KeyInfo内SPKIData要素は、公開鍵ペア、証明書や他のSPKIデータをSPKIに関する情報を伝えるために使用されます。 SPKISexpはSPKI正規のS-発現のbase64エンコーディングです。 SPKIDataは、少なくとも一つのSPKISexpを持っている必要があります。 SPKISexpはSPKIData内外部の空間から兄弟によって拡張/補完することができ、又はSPKIDataは完全のKeyInfoの子として別のSPKIのXML構造に置き換えることができます。
Schema Definition:
スキーマ定義：
<element name="SPKIData" type="ds:SPKIDataType"/> <complexType name="SPKIDataType"> <sequence maxOccurs="unbounded"> <element name="SPKISexp" type="base64Binary"/> <any namespace="##other" processContents="lax" minOccurs="0"/> </sequence> </complexType>
<要素名= "SPKIData" タイプ= "DS：SPKIDataType" /> <complexTypeの名前= "SPKIDataType"> <シーケンスのmaxOccurs = "無制限"> <要素名= "SPKISexp" タイプ= "base64Binaryの" /> <任意の名前空間= "##他の" のprocessContents = "緩い" のminOccurs = "0" /> </配列> </ complexTypeの>
DTD:
DTD：
<!ELEMENT SPKIData (SPKISexp %SPKIData.ANY;) > <!ELEMENT SPKISexp (#PCDATA) >
<！ELEMENT SPKIData（SPKISexp％SPKIData.ANY;）> <！ELEMENT SPKISexp（#PCDATA）>
Identifier Type="http://www.w3.org/2000/09/xmldsig#MgmtData" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ=「http://www.w3.org/2000/09/xmldsig#MgmtData」（これは、参照先の種類を識別するために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. Use of this element is NOT RECOMMENDED. It provides a syntactic hook where in-band key distribution or agreement data can be placed. However, superior interoperable child elements of KeyInfo for the transmission of encrypted keys and for key agreement are being specified by the W3C XML Encryption Working Group and they should be used instead of MgmtData.
KeyInfo内MgmtData要素は、帯域内鍵配布又は契約データを伝達するために使用される文字列の値です。たとえば、この要素のDH鍵交換、RSAキーの暗号化などの使用は推奨されません。これは、帯域内鍵配布又は契約データを配置することができる構文フックを提供します。しかし、暗号化キーの伝送のためと鍵合意のためのKeyInfoの優れた相互運用可能な子要素は、W3C XML暗号化ワーキンググループによって指定されていると、彼らは代わりにMgmtDataの使用すべきです。
Schema Definition:
スキーマ定義：
<element name="MgmtData" type="string"/>
<要素名= "MgmtData" タイプ= "文字列" />
DTD:
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 Object's Encoding attributed may be used to provide a URI that identifies the method by which the object is encoded (e.g., a binary file).
帰属オブジェクトのエンコード（例えば、バイナリファイル）オブジェクトを符号化する方法を識別するURIを提供するために使用されてもよいです。
The MimeType attribute is an optional attribute which describes the data within the Object (independent of its encoding). This is a string with values defined by [MIME]. For example, if the Object contains base64 encoded PNG, the Encoding may be specified as 'base64' and the MimeType as 'image/png'. This attribute is purely advisory; no validation of the MimeType information is required by this specification. Applications which require normative type and encoding information for signature validation should specify Transforms with well defined resulting types and/or encodings.
MIMEタイプ属性は、オブジェクト（そのコードの独立した）内のデータを記述するオプションの属性です。これは、[MIME]で定義された値を文字列です。オブジェクトはPNG base64エンコードが含まれている場合、例えば、符号化は「BASE64」と「画像/ PNG」などのMIMEタイプとして指定することができます。この属性は純粋に助言です。 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要素の上に計算されます。
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.
アプリケーションは、<オブジェクト>を除外することを希望する場合は、注意してくださいダイジェスト計算からタグは、リファレンス（XML文書のための簡単な）実際のデータオブジェクトを識別しなければならないか、データオブジェクトがどこにある可能性が高い（オブジェクトタグを削除するために使用されなければならない変換します非XML）。オブジェクトタグの排除は、1つのデータオブジェクトが署名（またはその逆）の外側に署名内部から移動された場合、署名は有効なまましたい場合のために所望され得る、またはオブジェクトの内容は、ANの符号化です元のバイナリ文書と元のビット単位の表現を署名するように抽出してデコードすることが望まれています。
Schema Definition:
スキーマ定義：
<element name="Object" type="ds:ObjectType"/> <complexType name="ObjectType" mixed="true"> <sequence minOccurs="0" maxOccurs="unbounded"> <any namespace="##any" processContents="lax"/> </sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="MimeType" type="string" use="optional"/> <attribute name="Encoding" type="anyURI" use="optional"/> </complexType>
<要素名= "オブジェクト" タイプ= "DS：のObjectType" /> <complexTypeの名= "のObjectType" 混合= "真"> <配列のminOccurs = "0" のmaxOccurs = "無制限"> <名前空間= "##いずれか"のprocessContents =" 緩い "/> </シーケンス> <属性名=" ID」タイプ= "ID" 使用= "オプション" /> <属性名= "MIMEタイプ" タイプ= "文字列" 使用= "オプション" /> <属性名= "エンコード" タイプ= "anyURIの" 使用= "オプション" /> </ complexTypeの>
DTD:
DTD：
<!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest %Object.ANY;)* > <!ATTLIST Object Id ID #IMPLIED MimeType CDATA #IMPLIED Encoding CDATA #IMPLIED >
<！ELEMENTオブジェクト（#PCDATA |署名| SignatureProperties |マニフェスト％の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.
マニフェスト要素は、参照の一覧を提供します。 SignedInfo内のリストとの違いは、オブジェクトが失敗した比較アクセスできないまたはダイジェストであれば、実際に参照しているオブジェクトと何をすべきかと照合されているダイジェストの、もしあれば、アプリケーション定義されていることです。マニフェストのSignedInfoから指されている場合は、マニフェスト自体を超えるダイジェストは、コア、署名の検証動作によってチェックされます。そのようなマニフェスト内のダイジェストは、アプリケーションの裁量でチェックされます。マニフェストは、別のマニフェストから参照されている場合は、この2つのレベルの深マニフェストのも、全体のダイジェストがチェックされない場合があります。
Schema Definition:
スキーマ定義：
<element name="Manifest" type="ds:ManifestType"/> <complexType name="ManifestType"> <sequence> <element ref="ds:Reference" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType>
<要素名= "マニフェスト" タイプ= "DS：ManifestType" /> <complexTypeの名前= "ManifestType"> <シーケンス> <要素REF = "DS：リファレンス" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの>
DTD:
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).
署名（S）の生成に関する追加情報項目はSignatureProperty要素（即ち、日付/タイムスタンプまたは署名の生成に使用される暗号化ハードウェアのシリアル番号）内に配置することができます。
Schema Definition:
スキーマ定義：
<element name="SignatureProperties" type="ds:SignaturePropertiesType"/> <complexType name="SignaturePropertiesType"> <sequence> <element ref="ds:SignatureProperty" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType>
<要素名= "SignatureProperties" タイプ= "DS：SignaturePropertiesType" /> <complexTypeの名前= "SignaturePropertiesType"> <シーケンス> <要素REF = "DS：SignatureProperty" のmaxOccurs = "無制限" /> </シーケンス> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの>
<element name="SignatureProperty" type="ds:SignaturePropertyType"/> <complexType name="SignaturePropertyType" mixed="true"> <choice maxOccurs="unbounded"> <any namespace="##other" processContents="lax"/> <!-- (1,1) elements from (1,unbounded) namespaces --> </choice> <attribute name="Target" type="anyURI" use="required"/> <attribute name="Id" type="ID" use="optional"/> </complexType>
<要素名= "SignatureProperty" タイプ= "DS：SignaturePropertyType" /> <complexTypeの名= "SignaturePropertyType" 混合= "真の"> <選択肢のmaxOccurs = "無制限"> <任意の名前空間= "##他" のprocessContents = "ずさん"/> <！ - （1、無制限）名前空間から（1,1）の要素 - > </選択> <属性名=" ターゲット」タイプ= "anyURIの" 使用= "必須" /> <属性名= "ID" タイプ= "ID" 使用= "オプション" /> </ complexTypeの>
DTD:
DTD：
<!ELEMENT SignatureProperties (SignatureProperty+) > <!ATTLIST SignatureProperties Id ID #IMPLIED >
<！ELEMENT SignatureProperties（SignatureProperty +）> <！ATTLIST SignaturePropertiesイドID #IMPLIED>
<!ELEMENT SignatureProperty (#PCDATA %SignatureProperty.ANY;)* > <!ATTLIST SignatureProperty Target CDATA #REQUIRED Id ID #IMPLIED >
<！ELEMENT SignatureProperty（#PCDATA％の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 identified within this specification retain PIs. When a PI is part of content that is signed (e.g., within SignedInfo or referenced XML documents) any change to the PI will obviously result in a signature failure.
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、および実装のための一連の要件を定義します。要件はありません、署名に使用するための要件上、実装上の指定されています。また、機構は、拡張可能です。別のアルゴリズムは、署名アプリケーションによって使用されてもよいです。
Digest 1. Required SHA1 http://www.w3.org/2000/09/xmldsig#sha1 Encoding 1. Required base64 http://www.w3.org/2000/09/xmldsig#base64 MAC 1. Required HMAC-SHA1 http://www.w3.org/2000/09/xmldsig#hmac-sha1 Signature 1. Required DSAwithSHA1 (DSS) http://www.w3.org/2000/09/xmldsig#dsa-sha1 2. Recommended RSAwithSHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 Canonicalization 1. Required Canonical XML (omits comments) http://www.w3.org/TR/2001/REC-xml-c14n-20010315 2. Recommended Canonical XML with Comments http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments Transform 1. Optional XSLT http://www.w3.org/TR/1999/REC-xslt-19991116 2. Recommended XPath http://www.w3.org/TR/1999/REC-xpath-19991116 3. Required Enveloped Signature* http://www.w3.org/2000/09/xmldsig#enveloped-signature
ダイジェスト1.必要なSHA1 http://www.w3.org/2000/09/xmldsig#sha1のエンコード1.必要なbase64でhttp://www.w3.org/2000/09/xmldsig#base64 MAC 1.必要なHMAC- SHA1 http://www.w3.org/2000/09/xmldsig#hmac-sha1署名1.必要なDSAwithSHA1（DSS）http://www.w3.org/2000/09/xmldsig#dsa-sha1 2.推奨RSAwithSHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1正規化1.必要な正規XML（コメントは省略）http://www.w3.org/TR/2001/REC-xml-c14n- 20010315 2.コメント付きCanonicalはXMLを推奨http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments 1.オプションXSLTトランスフォームhttp://www.w3.org/TR/1999/ XPathのhttp://www.w3.org/TR/1999/REC-xpath-19991116 3.必要なエンベロープ署名* http://www.w3.org/2000/09/xmldsig#推奨REC-XSLT-19991116 2包ま署名
* The Enveloped Signature transform removes the Signature element from the calculation of the signature when the signature is within the content that it is being signed. This MAY be implemented via the RECOMMENDED XPath specification specified in 6.6.4: Enveloped Signature Transform; it MUST have the same effect as that specified by the XPath Transform.
*エンベロープ署名変換署名が署名されているコンテンツ内にある場合、署名の計算から署名要素を除去します。これは、6.6.4で述べた推奨XPath仕様を介して実装されてもよい：エンベロープ署名を変換します;それは、XPath変換で指定されたものと同じ効果を持っていなければなりません。
Only one digest algorithm is defined herein. However, it is expected that one or more additional strong digest algorithms will be developed in connection with the US Advanced Encryption Standard effort. Use of MD5 [MD5] is NOT RECOMMENDED because recent advances in cryptanalysis have cast doubt on its strength.
唯一のダイジェストアルゴリズムが定義されます。しかし、1つの以上の追加の強いダイジェストアルゴリズムは、米国の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:
SHA-1アルゴリズム[SHA-1]は、明示的なパラメータを取りません。 SHA-1 DigestAlg素子の一例です。
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestMethodアルゴリズム= "http://www.w3.org/2000/09/xmldsig#sha1" />
A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. For example, the DigestValue element for the message digest:
SHA-1ダイジェストは160ビット列です。 DigestValue元素の含有量は、20オクテットのオクテットストリームとして見このビット列のbase64エンコーディングでなければなりません。例えば、メッセージダイジェスト用DigestValue要素：
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be:
SHA-1規格の付録Aから次のようになります。
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
<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="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> <HMACOutputLength>128</HMACOutputLength> </SignatureMethod>
<のSignatureMethodアルゴリズム= "http://www.w3.org/2000/09/xmldsig#hmac-sha1"> <HMACOutputLength> 128 </ HMACOutputLength> </のSignatureMethod>
The output of the HMAC algorithm is ultimately the output (possibly truncated) of the chosen digest algorithm. This value shall be base64 encoded in the same straightforward fashion as the output of the digest algorithms. Example: the SignatureValue element for the HMAC-SHA1 digest
HMACアルゴリズムの出力は、最終的に選択されたダイジェストアルゴリズムの出力（おそらくは切り捨て）です。この値は、ダイジェストアルゴリズムの出力と同じ簡単な方法でbase64エンコードされなければなりません。例：HMAC-SHA1ダイジェストのためのSignatureValue要素
9294727A 3638BB1C 13F48EF8 158BFC9D
9294727A 3638BB1C 13F48EF8 158BFC9D
from the test vectors in [HMAC] would be
[HMAC]のテストベクトルからなり
<SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>
<SignatureValue> kpRyejY4uxwT9I74FYv8nQ == </ SignatureValue>
Schema Definition:
スキーマ定義：
<simpleType name="HMACOutputLengthType"> <restriction base="integer"/> </simpleType>
<単純名= "HMACOutputLengthType"> <制限ベース= "整数" /> </ simpleTypeの>
DTD:
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="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<のSignatureMethodアルゴリズム= "http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
The output of the DSA algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value consists of the base64 encoding of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s in that order. Integer to octet-stream conversion must be done according to the I2OSP operation defined in the RFC 2437 [PKCS1] specification with a l parameter equal to 20. For example, the SignatureValue element for a DSA signature (r, s) with values specified in hexadecimal:
DSAアルゴリズムの出力は、通常、ペア（R、S）によって参照される整数の組から成ります。署名値は、それぞれこの順に値rおよびsのオクテット符号化から生じる2オクテットストリームの連結のbase64エンコーディングから成ります。整数オクテットストリームへの変換は、16進数で指定された値を持つ例えば20に等しいらパラメータ、DSA署名のためのSignatureValue要素（R、S）とRFC 2437 [PKCS1]仕様で定義されたI2OSP操作に応じて行われなければなりません：
r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
R = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 S = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
from the example in Appendix 5 of the DSS standard would be
DSS標準の付録5の例からだろう
<SignatureValue> i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA== </SignatureValue>
<SignatureValue> i6watmQQQ1y3GB + VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA == </ SignatureValue>
Identifier: http://www.w3.org/2000/09/xmldsig#rsa-sha1
識別しますhttp://www.w3.org/2000/09/xmldsig#rsa-sha1
The expression "RSA algorithm" as used in this document refers to the RSASSA-PKCS1-v1_5 algorithm described in RFC 2437 [PKCS1]. The RSA algorithm takes no explicit parameters. An example of an RSA SignatureMethod element is:
本書で使用される表現「RSAアルゴリズムは、」RFC 2437 [PKCS1]に記載のRSASSA-PKCS1-v1_5のアルゴリズムを指します。 RSAアルゴリズムは、明示的なパラメータを取りません。 RSAのSignatureMethod要素の例です。
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<のSignatureMethodアルゴリズム= "http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
The SignatureValue content for an RSA signature is the base64 [MIME] encoding of the octet string computed as per RFC 2437 [PKCS1, section 8.1.1: Signature generation for the RSASSA-PKCS1-v1_5 signature scheme]. As specified in the EMSA-PKCS1-V1_5-ENCODE function RFC 2437 [PKCS1, section 9.2.1], the value input to the signature function MUST contain a pre-pended algorithm object identifier for the hash function, but the availability of an ASN.1 parser and recognition of OIDs are not required of a signature verifier. The PKCS#1 v1.5 representation appears as:
RSA署名のためのSignatureValueコンテンツがRFC 2437に従って計算オクテットストリングの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 concatenation, "01", "FF", and "00" are fixed octets of the corresponding hexadecimal value, "hash" is the SHA1 digest of the data, and "prefix" is the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC 2437], that is,
ここで、「|」連結、「01」、「FF」、及び「00」は、対応する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> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639 In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw= </SignatureValue>
<SignatureValue> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0 / gyTE96639 In0FZFY2 / RVP + / bMJ01EArmKZsR5VW3rwoPxw = </ SignatureValue>
If canonicalization is performed over octets, the canonicalization algorithms take two implicit parameters: the content and its charset. The charset is derived according to the rules of the transport protocols and media types (e.g., RFC2376 [XML-MT] defines the media types for XML). This information is necessary to correctly sign and verify documents and often requires careful server side configuration.
コンテンツとその文字コード：正規化がオクテット上で実行されている場合は、正規化アルゴリズムは、2つの暗黙のパラメータを取ります。文字セット（例えば、RFC2376 [XML-MT]はXMLのメディアタイプを定義する）トランスポートプロトコルとメディアタイプのルールに従って導出されます。この情報は正しく文書に署名し、検証する必要があると、多くの場合、慎重にサーバー側の設定が必要です。
Various canonicalization algorithms require conversion to [UTF-8]. The two algorithms below understand at least [UTF-8] and [UTF-16] as input encodings. We RECOMMEND that externally specified algorithms do the same. Knowledge of other encodings is OPTIONAL.
種々の正規化アルゴリズムは、[UTF-8]への変換を必要とします。以下の2つのアルゴリズムは、少なくとも[UTF-8]、[UTF-16]入力エンコーディングとして理解します。私たちは、外部から指定されたアルゴリズムが同じことを行うことをお勧めします。他のエンコーディングの知識は任意です。
Various canonicalization algorithms transcode from a non-Unicode encoding to Unicode. The two algorithms below perform text normalization during transcoding [NFC, NFC-Corrigendum]. We RECOMMEND that externally specified canonicalization algorithms do the same. (Note, there can be ambiguities in converting existing charsets to Unicode, for an example see the XML Japanese Profile [XML-Japanese] Note.)
種々の正規化アルゴリズムはUnicodeに非Unicodeエンコーディングからトランスコード。 2つのアルゴリズムは、以下のトランスコーディング[NFC、NFC-正誤表]中のテキストの正規化を行います。私たちは、外部から指定された正規化アルゴリズムは同じことを行うことをお勧めします。 （例えば、XML日本語プロファイル[XML-日本語]注を参照して、Unicodeに既存の文字セットを変換する際にあいまいさが存在することができることに注意してください。）
Identifier for REQUIRED Canonical XML (omits comments): http://www.w3.org/TR/2001/REC-xml-c14n-20010315
REQUIRED正規XML（コメントは省略）のための識別子：http://www.w3.org/TR/2001/REC-xml-c14n-20010315
Identifier for Canonical XML with Comments: http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
コメント付きCanonicalはXMLのための識別子：http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
An example of an XML canonicalization element is: <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
XMLの正規化要素の例である：<CanonicalizationMethodにアルゴリズム=「http://www.w3.org/TR/2001/REC-xml-c14n-20010315」/>
The normative specification of Canonical XML is [XML-C14N]. The algorithm is capable of taking as input either an octet stream or an XPath node-set (or sufficiently functional alternative). The algorithm produces an octet stream as output. Canonical XML is easily parameterized (via an additional URI) to omit or retain comments.
カノニカルXMLの規範的仕様は[XML-C14N]です。アルゴリズムは、入力としてオクテットストリームまたはXPathノードセット（または十分に機能的な代替）のいずれかをとることが可能です。アルゴリズムは出力としてオクテットストリームを生成します。カノニカルXMLを容易に省略やコメントを保持する（追加のURIを介して）パラメータ化されます。
A Transform algorithm has a single implicit parameter: an octet stream from the Reference or the output of an earlier Transform.
基準からのオクテットストリーム以前変換の出力：変換アルゴリズムは、単一の暗黙のパラメータを有しています。
Application developers are strongly encouraged to support all transforms listed in this section as RECOMMENDED unless the application environment has resource constraints that would make such support impractical. Compliance with this recommendation will maximize application interoperability and libraries should be available to enable support of these transforms in applications without extensive development.
アプリケーション開発者は、強力なアプリケーション環境は、このようなサポートは非現実的になるだろう、リソースの制約がない限り、推奨されているように、このセクションに記載されているすべての変換をサポートすることをお勧めします。この勧告の遵守は、アプリケーションの相互運用性を最大化するとライブラリは、大規模な開発せずにアプリケーションでこれらの変換のサポートを有効にするために利用可能であるべきです。
Any canonicalization algorithm that can be used for CanonicalizationMethod (such as those in Canonicalization Algorithms (section 6.5)) can be used as a Transform.
（そのような正規化アルゴリズム（セクション6.5）のもののような）CanonicalizationMethodにするために使用することができる任意の正規化アルゴリズムを変換として使用することができます。
Identifiers: http://www.w3.org/2000/09/xmldsig#base64
識別子：http://www.w3.org/2000/09/xmldsig#base64
The normative specification for base64 decoding transforms is [MIME]. The base64 Transform element has no content. The input is decoded by the algorithms. This transform is useful if an application needs to sign the raw data associated with the encoded content of an element.
BASE64のデコード変換するための規範的な仕様は、[MIME]です。 BASE64変換を要素にはコンテンツがありません。入力は、アルゴリズムによって復号されます。これは、変換アプリケーションが要素のエンコードされたコンテンツに関連付けられた生データを署名する必要がある場合に有用です。
This transform requires an octet stream for input. If an XPath node-set (or sufficiently functional alternative) is given as input, then it is converted to an octet stream by performing operations logically equivalent to 1) applying an XPath transform with expression self::text(), then 2) taking the string-value of the node-set. Thus, if an XML element is identified by a barename XPointer in the Reference URI, and its content consists solely of base64 encoded character data, then this transform automatically strips away the start and end tags of the identified element and any of its descendant elements as well as any descendant comments and processing instructions. The output of this transform is an octet stream.
この変換は、入力のためのオクテットストリームが必要です。 XPathノードセット（または十分に機能的な代替）が入力として与えられた場合、それは、1）と論理的に等価な演算を実行することによってオクテットストリームに変換され、発現自己と変換XPathを適用::テキスト（）、次いで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による使用に適しにオクテットストリームを変換しなければなりません。 （必須カノニカル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 [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ドキュメントに表示されない場合、この式はエラーになります。
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="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> ... <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath xmlns:dsig="&dsig;"> not(ancestor-or-self::dsig:Signature) </XPath> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue></DigestValue> </Reference> </SignedInfo> <SignatureValue></SignatureValue> </Signature> ... </Document>
<ドキュメント> ... <署名のxmlns = "http://www.w3.org/2000/09/xmldsig#"> <た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, but may only be applied to a node-set from its parent XML document. Note that it is not necessary to use an XPath expression evaluator to create this transform. However, this transform MUST produce output in exactly the same manner as the XPath transform parameterized by the XPath expression above.
この変換の入出力要求は、XPath変換のものと同一であるが、唯一のノードセット親XML文書からにも適用することができます。この変換を作成するために、XPath式エバリュエータを使用する必要はないことに注意してください。しかし、これは、XPathは、上記のXPath式によってパラメータ化変換と全く同じ方法で出力を生成しなければならない変換します。
Identifier: http://www.w3.org/TR/1999/REC-xslt-19991116
識別しますhttp://www.w3.org/TR/1999/REC-xslt-19991116
The normative specification for XSL Transformations is [XSLT]. Specification of a namespace-qualified stylesheet element, which MUST be the sole child of the Transform element, indicates that the specified style sheet should be used. Whether this instantiates in-line processing of local XSLT declaration within the resource is determined by the XSLT processing model; the ordered application of multiple stylesheet may require multiple Transforms. No special provision is made for the identification of a remote stylesheet at a given URI because it can be communicated via an xsl:include or xsl:import within the stylesheet child of the Transform.
XSL変換のための規範的な仕様は、[XSLT]です。変換要素の唯一の子でなければならない名前空間修飾stylesheet要素の仕様は、指定されたスタイルシートを使用する必要があることを示します。これはXSLT処理モデルによって決定されたリソース内のローカルXSLT宣言のインライン処理をインスタンス化するかどうか。複数のスタイルシートの順序付けされたアプリケーションは、複数の変換が必要な場合があります。包含またはXSL：変換のスタイルシート子内のインポートがXSLを介して通信することができるので、特別な規定が与えられたURIのリモートスタイルシートの識別のために作られていません。
This transform requires an octet stream as input. If the actual input is an XPath node-set, then the signature application should attempt to convert it to octets (apply Canonical XML]) as described in the Reference Processing Model (section 4.3.3.2).
この変換は、入力としてオクテットストリームが必要です。実際の入力がXPathノード設定されている場合、署名アプリケーションリファレンス処理モデル（セクション4.3.3.2）で説明したように（]カノニカルXMLを適用）のオクテットに変換することを試みるべきです。
The output of this transform is an octet stream. The processing rules for the XSL style sheet or transform element are stated in the XSLT specification [XSLT]. We RECOMMEND that XSLT transform authors use an output method of xml for XML and HTML. As XSLT implementations do not produce consistent serializations of their output, we further RECOMMEND inserting a transform after the XSLT transform to canonicalize the output. These steps will help to ensure interoperability of the resulting signatures among applications that support the XSLT transform. Note that if the output is actually HTML, then the result of these steps is logically equivalent [XHTML].
この変換の出力は、オクテットストリームです。 XSLスタイルシートまたは要素を変換処理規則はXSLT仕様[XSLT]に記載されています。私たちは、XSLT変換、著者はXMLとHTMLのXMLの出力方法を使用することをお勧めします。 XSLTの実装は、その出力の一貫したシリアライズを生じないように、我々はさらにXSLTは出力を正規化するために変換した後、変換を挿入することをお勧めします。これらの手順は、XSLT変換をサポートしているアプリケーションの中で結果の署名の相互運用性を確保するのに役立ちます。出力が実際にHTMLであれば、これらのステップの結果は、[XHTML]論理的に等価であることに注意してください。
Digital signatures only work if the verification calculations are performed on exactly the same bits as the signing calculations. If the surface representation of the signed data can change between signing and verification, then some way to standardize the changeable aspect must be used before signing and verification. For example, even for simple ASCII text there are at least three widely used line ending sequences. If it is possible for signed text to be modified from one line ending convention to another between the time of signing and signature verification, then the line endings need to be canonicalized to a standard form before signing and verification or the signatures will break.
検証計算は署名計算と全く同じビット上で実行されている場合、デジタル署名のみ働きます。署名されたデータの表面表現が署名と検証の間で変更することができる場合、変更態様を標準化するためにいくつかの方法は、署名と検証の前に使用しなければなりません。例えば、でも単純なASCIIテキストのために、少なくとも3つの広く使われている行末シーケンスが存在します。署名されたテキストは、署名と署名検証の時間の間に別の規則を終了一行から変更することは可能である場合、行末は、署名及び検証又は署名が破損する前に標準形式に正規化する必要があります。
XML is subject to surface representation changes and to processing which discards some surface information. For this reason, XML digital signatures have a provision for indicating canonicalization methods in the signature so that a verifier can use the same canonicalization as the signer.
XMLは、表面表現の変更及び一部の表面情報を破棄し、処理の対象となります。この理由のために、XMLデジタル署名は、検証者は、署名者と同じ正規化を使用できるように署名に正規化方法を示すための設備を有しています。
Throughout this specification we distinguish between the canonicalization of a Signature element and other signed XML data objects. It is possible for an isolated XML document to be treated as if it were binary data so that no changes can occur. In that case, the digest of the document will not change and it need not be canonicalized if it is signed and verified as such. However, XML that is read and processed using standard XML parsing and processing techniques is frequently changed such that some of its surface representation information is lost or modified. In particular, this will occur in many cases for the Signature and enclosed SignedInfo elements since they, and possibly an encompassing XML document, will be processed as XML.
本明細書を通して、我々は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 four categories. There are those related to the basic [XML], as described in 7.1 below. There are those related to [DOM], [SAX], or similar processing as described in 7.2 below. Third, there is the possibility of coded character set conversion, such as between UTF-8 and UTF-16, both of which all [XML] compliant processors are required to support, which is described in the paragraph immediately below. And, fourth, there are changes that related to namespace declaration and XML namespace attribute context as described in 7.3 below.
正規化する必要があるかもしれないXMLの変更の種類は4つのカテゴリに分けることができます。下記7.1に記載されるように、基本的な[XML]に関連するものがあります。下記7.2に記載されるように[DOM]、[SAX]、または同様の処理に関連するものがあります。第三に、そのようなすぐ下の段落に記載されているすべての[XML]準拠プロセッサがサポートする必要があるどちらもUTF-8およびUTF-16、との間のような符号化された文字セット変換の可能性があります。そして、第四、以下の7.3で説明したように、名前空間宣言とXML名前空間属性のコンテキストに関連した変化があります。
Any canonicalization algorithm should yield output in a specific fixed coded character set. All canonicalization algorithms identified in this document use UTF-8 (without a byte order mark (BOM)) and do not provide character normalization. We RECOMMEND that signature applications create XML content (Signature elements and their descendents/content) in Normalization Form C [NFC, NFC-Corrigendum] and check that any XML being consumed is in that form as well; (if not, signatures may consequently fail to validate). Additionally, none of these algorithms provide data type normalization. Applications that normalize data types in varying formats (e.g., (true, false) or (1,0)) may not be able to validate each other's signatures.
任意の正規化アルゴリズムは、特定の固定コード化文字セットで出力が得られるはずです。 （バイトオーダーマーク（BOM）なし）このドキュメントの使用UTF-8で特定され、すべての正規化アルゴリズムは、文字の正規化を提供していません。我々は、署名アプリケーションは正規化形式C [NFC、NFC-正誤表]の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, 4. entity references are replaced with the corresponding declared entity, 5. attribute values are normalized by 5.1 replacing character and entity references as above, 5.2 replacing occurrences of #x9, #xA, and #xD with #x20 (space) except that the sequence #xD#xA is replaced by a single space, and 5.3 if the attribute is not declared to be CDATA, stripping all leading and trailing spaces and replacing all interior runs of spaces with a single space.
1.行末は、彼らはすぐにの#xAが続いている場合#xD文字を落とし、他のすべてのケースでの#xAに置き換えることにより、単一の文字の#xAに正規化され、2不足している属性がに提供されるデフォルト値を持つように宣言しますデフォルト値を持つ存在する場合、アプリケーションは、3文字参照は、対応する文字に置き換えられ、4実体参照は、対応する宣言エンティティに置き換えられ、前記属性値は5.2置き換え、上記のように文字やエンティティ参照を置き換える5.1によって正規化されますすべての先頭と末尾のスペースを除去属性がCDATAであると宣言されていない場合、シーケンスは、＃xDさん＃xAでは、単一のスペース、および5.3で置き換えられることを除き、＃のX9、の#xA、および＃のX20と#xD（スペース）の出現、そして単一のスペースとスペースのすべての内部の実行を交換します。
Note that items (2), (4), and (5.3) depend on the presence of a schema, DTD or similar declarations. The Signature element type is laxly schema valid [XML-schema], consequently external XML or even XML within the same document as the signature may be (only) well-formed or from another namespace (where permitted by the signature schema); the noted items may not be present. Thus, a signature with such content will only be verifiable by other signature applications if the following syntax constraints are observed when generating any signed material including the SignedInfo element:
項目（2）、（4）、及び（5.3）スキーマ、DTDまたは同様の宣言の存在に依存することに留意されたいです。 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 DOM or SAX processing, a canonical method is needed to serialize the relevant part of a DOM tree or sequence of SAX events. XML canonicalization specifications, such as [XML-C14N], are based only on information which is preserved by DOM and SAX. For an XML Signature to be verifiable by an implementation using DOM or SAX, not only must the XML 1.0 syntax constraints given in the previous section be followed, but an appropriate XML canonicalization MUST be specified so that the verifier can re-serialize DOM/SAX mediated input into the same octet stream that was signed.
XML署名は、DOMまたはSAX処理を使用してシステム上に生成または検証される場合、カノニカル方法は、SAXイベントのDOMツリーまたは配列の関連部分をシリアル化するために必要とされます。このような[XML-C14N]としてXML正規化仕様は、唯一のDOMとSAXによって保存された情報に基づいています。 XML署名は、前のセクションで与えられたXML 1.0構文制約が従わなければならないが、適切なXML正規化は、検証を再シリアライズすることができるようにDOM / SAX指定されなければならないだけでなく、DOMやSAXを使用して実装することによって検証されるようにするため署名したのと同じオクテットストリームに入力を媒介しました。
In [XPath] and consequently the Canonical XML data model an element has namespace nodes that correspond to those declarations within the element and its ancestors:
【のXPath]で、その結果、正規のXMLデータモデル要素は、要素とその祖先の中にそれらの宣言に対応する名前空間ノードを有します。
"Note: An element E has namespace nodes that represent its namespace declarations as well as any namespace declarations made by its ancestors that have not been overridden in E's declarations, the default namespace if it is non-empty, and the declaration of the prefix xml." [XML-C14N]
「注：それが空であればEはその名前空間宣言を表す名前空間ノードだけでなく、Eの宣言で上書きされていないその祖先によって作られた任意の名前空間宣言、デフォルトの名前空間を持つ要素、およびプレフィックスXMLの宣言。」 [XML-C14N]
When serializing a Signature element or signed XML data that's the child of other elements using these data models, that Signature element and its children, may contain namespace declarations from its ancestor context. In addition, the Canonical XML and Canonical XML with Comments algorithms import all xml namespace attributes (such as xml:lang) from the nearest ancestor in which they are declared to the apex node of canonicalized XML unless they are already declared at that node. This may frustrate the intent of the signer to create a signature in one context which remains valid in another. For example, given a signature which is a child of B and a grandchild of A:
これらのデータモデル、そのSignature要素とその子を使用して他の要素の子の署名要素または署名したXMLデータをシリアル化するときは、その祖先コンテキストから名前空間宣言を含んでいてもよいです。彼らはすでに、そのノードで宣言されていない限り、それらは正規化されたXMLの頂点ノードに宣言されている最も近い祖先から：また、コメントアルゴリズムとCanonicalはXMLと正規XMLは（LANG XMLなど）すべてのXML名前空間の属性をインポートします。これは、別の有効なままであるコンテキスト内の署名を作成する署名者の意図を妨げることができます。例えば、BおよびAの孫の子であるシグネチャを所与。
<A xmlns:n1="&foo;"> <B xmlns:n2="&bar;"> <Signature xmlns="&dsig;"> ... <Reference URI="#signme"/> ... </Signature> <C ID="signme" xmlns="&baz;"/> </B> </A>
<A xmlns:n1="& foo;"> <Bのxmlns：N2 = "＆バー;"> <署名のxmlns = "＆DSIG;"> ... <参考URI = "＃1 signme" /> ... </署名> <C ID = "signme" のxmlns = "＆バズ;" /> </ B> </A>
when either the element B or the signed element C is moved into a [SOAP] envelope for transport:
素子Bまたは署名された素子Cのいずれかが[SOAP]に移動したときに搬送するための封筒。
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> ... <SOAP:Body> <B xmlns:n2="&bar;"> <Signature xmlns="&dsig;"> ... </Signature> <C ID="signme" xmlns="&baz;"/> </B> </SOAP:Body> </SOAP:Envelope>
<SOAP：エンベロープのxmlns：SOAP = "http://schemas.xmlsoap.org/soap/envelope/"> ... <SOAP：BODY> <Bののxmlns：N2 = "＆バー;"> <署名のxmlns =」 ＆DSIG; "> ... </署名> <C ID =" signme」のxmlns = "＆バズ;" /> </ B> </ SOAP：BODY> </ SOAP：エンベロープ>
The canonical form of the signature in this context will contain new namespace declarations from the SOAP:Envelope context, invalidating the signature. Also, the canonical form will lack namespace declarations it may have originally had from element A's context, also invalidating the signature. To avoid these problems, the application may:
署名を無効、封筒コンテキスト：このコンテキストでは、署名の正規の形式は、SOAPから新しい名前空間宣言が含まれています。また、正規の形式にも署名を無効、要素Aの文脈からそれが元々持っていたかもしれない名前空間宣言を欠いています。これらの問題を回避するには、アプリケーションがあります。
1. Rely upon the enveloping application to properly divorce its body (the signature payload) from the context (the envelope) before the signature is validated. Or, 2. Use a canonicalization method that "repels/excludes" instead of "attracts" ancestor context. [XML-C14N] purposefully attracts such context.
1.適切に署名が検証される前に、コンテキスト（エンベロープ）からその本体（署名ペイロード）離婚するエンベロープアプリケーションに依存します。または、2.祖先コンテキストを「集めて」の代わりに「/除外をはじく」という正規化メソッドを使用します。 [XML-C14N]は意図的にそのようなコンテキストを集めています。
The XML Signature specification provides a very flexible digital signature mechanism. Implementors must give consideration to their application threat models and to the following factors.
XML署名仕様は、非常に柔軟なデジタル署名メカニズムを提供します。実装者は、そのアプリケーションの脅威モデルにし、以下の要因を考慮を与える必要があります。
A requirement of this specification is to permit signatures to "apply to a part or totality of a XML document." (See [XML-Signature-RD, section 3.1.3].) The Transforms mechanism meets this requirement by permitting one to sign data derived from processing the content of the identified resource. For instance, applications that wish to sign a form, but permit users to enter a limited field data without invalidating a previous signature on the form might use [XPath] to exclude those portions the user needs to change. Transforms may be arbitrarily specified and may include encoding transforms, canonicalization instructions or even XSLT transformations. Three cautions are raised with respect to this feature in the following sections.
この仕様の要件がする署名を可能にすることである「XML文書の一部または全体に適用されます。」 （[XML-署名-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 applications may be satisfied with verifying an XML signature over a cached copy of already transformed data. Other applications might require that content be freshly dereferenced and transformed.
ノートは、コア検証動作は、署名されたデータが示す変換の各ステップを適用することによって得られたことを確認しません。例えば、（それが署名に指定された結果のコンテンツマッチのダイジェストことを確認してください。んが）、一部のアプリケーションは、すでに変換されたデータのキャッシュされたコピー上にXML署名を検証することに満足してもよいです。他のアプリケーションはコンテンツがたて逆参照して変換する必要があります。
First, obviously, signatures over a transformed document do not secure any information discarded by transforms: only what is signed is secure.
まず、明らかに、変換した文書を超える署名が変換によって廃棄されたすべての情報を保護していない：だけで何署名されていることは安全です。
Note that the use of Canonical XML [XML-C14N] ensures that all internal entities and XML namespaces are expanded within the content being signed. All entities are replaced with their definitions and the canonical form explicitly represents the namespace that an element would otherwise inherit. Applications that do not canonicalize XML content (especially the SignedInfo element) SHOULD NOT use internal entities and SHOULD represent the namespace explicitly within the content being signed since they cannot rely upon canonicalization to do this for them. Also, users concerned with the integrity of the element type definitions associated with the XML instance being signed may wish to sign those definitions as well (i.e., the schema, DTD, or natural language description associated with the namespace/identifier).
カノニカルXML [XML-C14N]の使用は、すべての内部エンティティとXML名前空間が署名されているコンテンツ内で拡張されることを確実にすることに留意されたいです。すべてのエンティティは、その定義と明示的要素がそうでなければ継承する名前空間を表している標準的な形式に置き換えられます。 XMLコンテンツ（特にSignedInfoエレメント）を正規化していないアプリケーションは、内部エンティティを使用すべきではなく、彼らは彼らのためにこれを行うために正規化に頼ることができないので、署名されているコンテンツの中に明示的に名前空間を表現して下さい。また、署名されるXMLインスタンスに関連付けられた要素タイプの定義の整合性に関するユーザは、同様に（すなわち、スキーマ、DTD、または名前空間/識別子に関連付けられている自然言語記述）をそれらの定義に署名することを望むかもしれません。
Second, an envelope containing signed information is not secured by the signature. For instance, when an encrypted envelope contains a signature, the signature does not protect the authenticity or integrity of unsigned envelope headers nor its ciphertext form, it only secures the plaintext actually signed.
第二に、署名された情報を含むエンベロープ署名によって保護されていません。暗号化された封筒には、署名が含まれている場合、署名が本物か符号なしエンベロープヘッダの整合性もその暗号文の形式を保護することはありません例えば、それだけで、実際に署名した平文を確保しています。
Additionally, the signature secures any information introduced by the transform: only what is "seen" (that which is represented to the user via visual, auditory or other media) should be signed. If signing is intended to convey the judgment or consent of a user (an automated mechanism or person), then it is normally necessary to secure as exactly as practical the information that was presented to that user. Note that this can be accomplished by literally signing what was presented, such as the screen images shown a user. However, this may result in data which is difficult for subsequent software to manipulate. Instead, one can sign the data along with whatever filters, style sheets, client profile or other information that affects its presentation.
（視覚、聴覚、または他のメディアを介してユーザに示されているもの）、「見」されているものだけを署名しなければならない。また、署名変換によって導入された任意の情報を確保します。署名は、ユーザー（自動化メカニズムまたは人）の判断や同意を伝えることを意図されている場合、正確に同じ実用的なように、そのユーザに提示された情報を保護するために通常必要です。これは、ユーザを示す画面画像として、文字通り提示されたものを署名することによって達成することができることに留意されたいです。しかし、これは、その後のソフトウェアを操作することは困難であるデータをもたらすことができます。代わりに、人はどんなフィルタ、スタイルシート、クライアントプロファイルまたはそのプレゼンテーションに影響を与え、他の情報と一緒にデータに署名することができます。
Just as a user should only sign what he or she "sees," persons and automated mechanism that trust the validity of a transformed document on the basis of a valid signature should operate over the data that was transformed (including canonicalization) and signed, not the original pre-transformed data. This recommendation applies to transforms specified within the signature as well as those included as part of the document itself. For instance, if an XML document includes an embedded style sheet [XSLT] it is the transformed document that should be represented to the user and signed. To meet this recommendation where a document references an external style sheet, the content of that external resource should also be signed via a signature Reference, otherwise the content of that external content might change which alters the resulting document without invalidating the signature.
ただ、ユーザーとしてだけ彼または彼女は有効な署名に基づいて変換された文書の妥当性を信頼者や自動化されたメカニズムは、（正規化を含む）を形質転換したデータ上で動作しなければならない「見ている」何に署名し、署名し、べきではありませんオリジナルの事前変換されたデータ。この勧告は、署名内の指定された変換と同様に、文書自体の一部として含まれるものに適用されます。 XML文書が埋め込まれたスタイルシートを含む場合、例えば、[XSLT]は、ユーザに提示し、署名しなければならない変換されたドキュメントです。ドキュメントが外部スタイルシートを参照し、この勧告を満たすために、その外部リソースの内容も、そうでない場合は、外部コンテンツの内容は、署名を無効にすることなく、結果の文書を変更した変更される可能性があり、署名リファレンスを経由して署名する必要があります。
Some applications might operate over the original or intermediary data but should be extremely careful about potential weaknesses introduced between the original and transformed data. This is a trust decision about the character and meaning of the transforms that an application needs to make with caution. Consider a canonicalization algorithm that normalizes character case (lower to upper) or character composition ('e and accent' to 'accented-e'). An adversary could introduce changes that are normalized and consequently inconsequential to signature validity but material to a DOM processor. For instance, by changing the case of a character one might influence the result of an XPath selection. A serious risk is introduced if that change is normalized for signature validation but the processor operates over the original data and returns a different result than intended.
一部のアプリケーションでは、オリジナルや中間のデータ上で動作する場合がありますが、元と変換されたデータの間に導入潜在的な弱点について非常に注意しなければなりません。これは、アプリケーションが慎重に行う必要がある変換の文字と意味についての信頼の決定です。文字ケース（上に下部）または文字組成物（「アクセント-E」に「eおよびアクセント」）を正規化する正規化アルゴリズムを考えます。敵対者は、DOMプロセッサに署名有効性が、材料に対して正規化し、その結果取るに足らないある変化を導入できました。例えば、文字の大文字と小文字を変更することで、1は、XPathの選択の結果に影響を与える可能性があります。その変更は、署名検証のために正規化されているが、プロセッサは、元のデータで動作し、意図とは異なる結果を返す場合、深刻なリスクが導入されます。
As a result:
結果として：
* All documents operated upon and generated by signature applications MUST be in [NFC, NFC-Corrigendum] (otherwise intermediate processors might unintentionally break the signature) * Encoding normalizations SHOULD NOT be done as part of a signature transform, or (to state it another way) if normalization does occur, the application SHOULD always "see" (operate over) the normalized form.
*署名アプリケーションによって操作および生成されたすべての文書は、[NFC、NFC-正誤表]でなければなりません*エンコーディング正規化は、変換署名の一部として行われるべきではなく、または（が別の状態（そうでなければ、中間のプロセッサは、意図せずに署名を壊すかもしれません）方法正規化が発生した場合）、アプリケーションは常に「見る」べきである（上で動作）正規化された形式。
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/Signature/Drafts/xmldsig-core/xmldsig-core-schema.xsd Valid XML schema instance based on the 20001024 Schema/DTD [XML-Schema].
20001024スキーマ/ DTD [XML-スキーマ]に基づいて、XML署名スキーマのインスタンスhttp://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-core-schema.xsd有効なXMLスキーマ・インスタンス。
XML Signature DTD http://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-core-schema.dtd
XML署名DTD http://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-core-schema.dtd
RDF Data Model http://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-datamodel-20000112.gif
RDFデータモデルhttp://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-datamodel-20000112.gif
XML Signature Object Example http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example.xml A cryptographical fabricated XML example that includes foreign content and validates under the schema, it also uses schemaLocation to aid automated schema fetching and validation.
XML署名対象例外国のコンテンツを含んでおり、スキーマの下で検証http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example.xml暗号学作製XMLの例では、それはまた、自動化されたスキーマを助けるためのschemaLocationを使用しますフェッチと検証。
RSA XML Signature Example http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example-rsa.xml An XML Signature example with generated cryptographic values by Merlin Hughes and validated by Gregor Karlinger.
RSA XML署名例http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example-rsa.xmlマーリン・ヒューズによって生成された暗号値を持つXML署名例及びグレKarlingerによって検証。
DSA XML Signature Example http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example-dsa.xml Similar to above but uses DSA.
上記と同様に、DSAのXML署名例http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example-dsa.xmlが、DSAを使用します。
Authentication Code (Protected Checksum) A value generated from the application of a shared key to a message via a cryptographic algorithm such that it has the properties of message authentication (and integrity) but not signer authentication. Equivalent to protected checksum, "A checksum that is computed for a data object by means that protect against active attacks that would attempt to change the checksum to make it match changes made to the data object." [SEC]
認証コード（チェックサムを保護）は、メッセージ認証（及び完全性）の性質を有するような暗号化アルゴリズムを介しメッセージに共有キーのアプリケーションから生成された値ではなく認証を署名者。保護されたチェックサムに相当「それはデータオブジェクトに加えられた変更を一致させるために、チェックサムを変更しようと積極的な攻撃から守る手段でデータオブジェクトに対して計算されたチェックサム。」 [秒]
Authentication, Message The property, given an authentication code/protected checksum, that tampering with both the data and checksum, so as to introduce changes while seemingly preserving integrity, are still detected. "A signature should identify what is signed, making it impracticable to falsify or alter either the signed matter or the signature without detection." [Digital Signature Guidelines, ABA]. Authentication, Signer The property of the identity of the signer is as claimed. "A signature should indicate who signed a document, message or record, and should be difficult for another person to produce without authorization." [Digital Signature Guidelines, ABA] Note, signer authentication is an application decision (e.g., does the signing key actually correspond to a specific identity) that is supported by, but out of the scope of, this specification. Checksum "A value that (a) is computed by a function that is dependent on the contents of a data object and (b) is stored or transmitted together with the object, for the purpose of detecting changes in the data." [SEC] Core The syntax and processing defined by this specification, including core validation. We use this term to distinguish other markup, processing, and applications semantics from our own. Data Object (Content/Document) The actual binary/octet data being operated on (transformed, digested, or signed) by an application -- frequently an HTTP entity [HTTP]. Note that the proper noun Object designates a specific XML element. Occasionally we refer to a data object as a document or as a resource's content. The term element content is used to describe the data between XML start and end tags [XML]. The term XML document is used to describe data objects which conform to the XML specification [XML]. Integrity "The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner." [SEC] A simple checksum can provide integrity from incidental changes in the data; message authentication is similar but also protects against an active attack to alter the data whereby a change in the checksum is introduced so as to match the change in the data. Object An XML Signature element wherein arbitrary (non-core) data may be placed. An Object element is merely one type of digital data (or document) that can be signed via a Reference.
認証、メッセージ一見完全性を維持しながら変化を導入するように、データおよびチェックサムの両方の改ざん、まだ検出されていることを、認証コード/保護されたチェックサムを指定されたプロパティ、。 「署名は、それが検出されずに署名した物質または署名のいずれかを改ざんまたは変更するために実行不可能なって、署名されているものを特定しなければなりません。」 [デジタル署名のガイドライン、ABA]。記載の認証、署名者の身元のプロパティを署名者があります。 「署名は、ドキュメント、メッセージまたはレコードに署名した人示す必要があり、そして他の人が許可なく生産するために困難にする必要があります。」 [デジタル署名ガイドライン、ABA]メモ、署名者の認証が、この明細書の範囲外で支持されているアプリケーションの決定（例えば、署名鍵が実際に特定のIDに対応しない）です。チェックサム「（a）は、データオブジェクトの内容に依存する関数によって計算された値（b）は、格納されたり、データの変化を検出するために、オブジェクトと一緒に送信されます」。 [秒]コアコア検証を含むこの仕様で定義された構文および処理。我々は我々自身から他のマークアップ、処理、およびアプリケーションのセマンティクスを区別するためにこの用語を使用します。データ・オブジェクト（コンテンツ/ドキュメント）は、実際のバイナリ/オクテットデータがアプリケーションによって（形質転換され、消化された、又は署名された）上で動作して - しばしばHTTPエンティティ[HTTP]。固有名詞のオブジェクトは、特定のXML要素を指定することに注意してください。時折、我々は文書としてまたはリソースのコンテンツとしてのデータオブジェクトを参照してください。用語要素のコンテンツは、[XML] XML開始タグと終了タグとの間でデータを記述するために使用されます。用語XML文書は、XML仕様[XML]に準拠したデータオブジェクトを記述するために使用されます。整合性「のデータは、変更され破壊され、あるいは不正または偶発的に失われていない財産。」 [秒]単純なチェックサムはデータに付帯変化から完全性を提供することができます。メッセージ認証も同様であるが、データの変化に合わせて、チェックサムの変化が導入されるデータを変更するために積極的な攻撃から保護します。任意（非コア）データが配置されていてもよい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/octets
being operated upon.
Signature
Formally speaking, a value generated from the application of a
private key to a message via a cryptographic algorithm such that
it has the properties of integrity, message authentication and/or
signer authentication. (However, we sometimes use the term
signature generically such that it encompasses Authentication Code
values as well, but we are careful to make the distinction when
the property of signer authentication is relevant to the
exposition.) A signature may be (non-exclusively) described as
detached, enveloping, or enveloped.
Signature, Application
An application that implements the MANDATORY (REQUIRED/MUST)
portions of this specification; these conformance requirements are
over application behavior, the structure of the Signature element
type and its children (including SignatureValue) and the specified
algorithms.
Signature, Detached
The signature is over content external to the Signature element,
and can be identified via a URI or transform. Consequently, the
signature is "detached" from the content it signs. This
definition typically applies to separate data objects, but it also
includes the instance where the Signature and data object reside
within the same XML document but are sibling elements.
Signature, Enveloping
The signature is over content found within an Object element of
the signature itself. The Object (or its content) is identified
via a Reference (via a URI fragment identifier or transform).
Signature, Enveloped
The signature is over the XML content that contains the signature
as an element. The content provides the root XML document
element. Obviously, enveloped signatures must take care not to
include their own value in the calculation of the SignatureValue.
Transform The processing of a data from its source to its derived form. Typical transforms include XML Canonicalization, XPath, and XSLT. Validation, Core The core processing requirements of this specification requiring signature validation and SignedInfo reference validation. Validation, Reference The hash value of the identified and transformed content, specified by Reference, matches its specified DigestValue. Validation, Signature The SignatureValue matches the result of processing SignedInfo with CanonicalizationMethod and SignatureMethod as specified in Core Validation (section 3.2). Validation, Trust/Application The application determines that the semantics associated with a signature are valid. For example, an application may validate the time stamps or the integrity of the signer key -- though this behavior is external to this core specification.
その派生形にそのソースからのデータの処理を変換します。典型的な変換はXML正規化、XPathの、およびXSLTが含まれます。検証、コア署名検証とのSignedInfo参照の検証を必要とする本明細書の中核処理要件。検証は、識別され、形質転換されたコンテンツのハッシュ値を参照、参照によって指定、その指定されたDigestValueと一致します。検証は、署名SignatureValueは、コア検証（セクション3.2）で指定されるようにCanonicalizationMethodにとのSignatureMethodと共にたSignedInfoを処理した結果と一致します。検証は、信頼/アプリケーションは、アプリケーションが署名に関連付けられたセマンティクスが有効であると判断します。例えば、アプリケーションは、タイムスタンプまたは署名キーの完全性を検証することができる - この動作は、このコア仕様の外部にあるけれども。
Appendix: Changes from RFC 3075
付録：RFC 3075からの変更点
Numerous minor editorial changes were made. In addition, the following substantive changes have occurred based on interoperation experience or other considerations:
多くのマイナーな編集上の変更が行われました。また、以下の実質的な変更は、相互運用の経験や他の考慮事項に基づいて発生しています：
1. Minor but incompatible changes in the representation of DSA keys. In particular, the optionality of several fields was changed and two fields were re-ordered.
DSA鍵の表現1.マイナーが、互換性のない変更。具体的には、いくつかのフィールドの選択性を変更し、2つのフィールドは、再注文しました。
2. Minor change in the X509Data KeyInfo structure to allow multiple CRLs to be grouped with certificates and other X509 information. Previously CRLs had to occur singly and each in a separate X509Data structure.
複数のCRLは、証明書や他のX509情報とグループ化されることを可能にするX509DataのKeyInfo構造2.マイナーチェンジ。以前CRLは別個X509Data構造に単独で、それぞれ発生しなければなりませんでした。
3. Incompatible change in the type of PGPKeyID, which had previously been string, to the more correct base64Binary since it is actually a binary quantity.
実際にバイナリ量であるため、以前より正確base64Binaryのために、文字列であったPGPKeyIDのタイプ、3.非互換の変更。
4. Several warnings have been added. Of particular note, because it reflects a problem actually encountered in use and is the only warning added that has its own little section, is the warning of canonicalization problems when the namespace context of signed material changes.
4.いくつかの警告が追加されました。特に注目すべきなのは、それが実際に使用して発生した問題を反映していると警告のみが自身の小さなセクションを持っていることを追加しているため、正規化の問題時に署名した材料の変更の名前空間コンテキストの警告です。
References
リファレンス
[ABA] Digital Signature Guidelines. http://www.abanet.org/scitech/ec/isc/dsgfree.html
[ABA]デジタル署名のガイドライン。 http://www.abanet.org/scitech/ec/isc/dsgfree.html
[DOM] Document Object Model (DOM) Level 1 Specification. W3C Recommendation. V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, L. Wood. October 1998. http://www.w3.org/TR/1998/REC-DOM-Level-1- 19981001/
[DOM]ドキュメントオブジェクトモデル（DOM）レベル1の仕様。 W3C勧告。 V. 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-2 . Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips186- 2/fips186-2.pdf
[DSS] FIPSパブ186-2。デジタル署名標準（DSS）。 、米国商務省/国立標準技術研究所。 http://csrc.nist.gov/publications/fips/fips186- 2 / fips186-2.pdf
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[HTTP] Fielding, R. Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]フィールディング、R.ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616年、1999年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[LDAP-DN] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[LDAP-DN]ワール、M.、Kille、S.とT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：識別名のUTF-8文字列表現"、RFC 2253、1997年12月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest氏、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[NFC] TR15, Unicode Normalization Forms. M. Davis, M. Drst. Revision 18: November 1999. http://www.unicode.org/unicode/reports/tr15/tr15- 18.html. NFC-Corrigendum Normalization Corrigendum. The Unicode Consortium. http://www.unicode.org/unicode/uni2errata/ Normalization_Corrigendum.html.
[NFC] TR15、Unicode正規化フォーム。 M.デイヴィス、M. DRST。リビジョン18：1999年11月http://www.unicode.org/unicode/reports/tr15/tr15- 18.html。 NFC-正誤表正規正誤表。ユニコードコンソーシアム。 http://www.unicode.org/unicode/uni2errata/ Normalization_Corrigendum.html。
[PGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[PGP]カラス、J.、Donnerhacke、L.、フィニー、H.及びR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[RANDOM] Eastlake, 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RANDOM]イーストレイク、第三、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[RDF] Resource Description Framework (RDF) Schema Specification 1.0. W3C Candidate Recommendation. D. Brickley, R.V. Guha. March 2000. http://www.w3.org/TR/2000/CR-rdf-schema-20000327/ Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation. O. Lassila, R. Swick. February 1999. http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
[RDF]リソース記述フレームワーク（RDF）スキーマ仕様1.0。 W3C勧告候補。 D. Brickleyが、R.V.グハ。 2000年3月http://www.w3.org/TR/2000/CR-rdf-schema-20000327/のRDF（Resource Description Framework）モデルとシンタックス仕様。 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.
[PKCS1] Kaliski、B.及びJ. Staddon、 "PKCS＃1：RSA暗号仕様バージョン2.0"、RFC 2437、1998年10月。
[SAX] SAX: The Simple API for XML. D. Megginson, et al. May 1998. http://www.megginson.com/SAX/index.html (THIS PAGE OUT OF DATE; GO TO www.saxproject.org)
[SAX] SAX：XML用のシンプルなAPI。 D. Megginson氏ら。 1998年にはhttp://www.megginson.com/SAX/index.htmlも（DATE OF THIS PAGE OUTは、www.saxproject.orgへ行きます）
[SEC] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[SEC] Shirey、R.、 "インターネットセキュリティ用語集"、FYI 36、RFC 2828、2000年5月。
[SHA-1] FIPS PUB 180-1. Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips180- 1/fip180-1.txt
[SHA-1] PUB 180-1 FIPS。ハッシュ標準を固定します。 、米国商務省/国立標準技術研究所。 http://csrc.nist.gov/publications/fips/fips180- 1 / fip180-1.txt
[SOAP] Simple Object Access Protocol (SOAP) Version 1.1. W3C Note. D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte, D. Winer. May 2001. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[SOAP]のSOAP（Simple Object Access Protocol）バージョン1.1。 W3Cに注意してください。 D.ボックス、D. Ehnebuske、G. Kakivaya、A.素人、N.メンデルゾーン、H. Frystykニールセン、S. Thatte、D.ワイナー。 2001年5月http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[Unicode] The Unicode Consortium. The Unicode Standard. http://www.unicode.org/unicode/standard/ standard.html
[UNICODE]ユニコードコンソーシアム。 Unicode標準。 http://www.unicode.org/unicode/standard/ standard.html
[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[UTF-16]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、2000年2月。
[UTF-8] Yergeau, R., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF-8] Yergeau、R.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[URI-Literal] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
"URLの中にリテラルIPv6アドレスのフォーマット" [URI-リテラル] HindenとR.、大工、B.およびL. Masinter、RFC 2732、1999年12月。
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[URN]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[X509v3] ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework" ISO/IEC 9594-8:1997.
[書X509v3] ITU-T勧告X.509のバージョン3（1997）。 「情報技術 - 開放型システム間相互接続 - ディレクトリ認証フレームワーク」ISO / IEC 9594から8：1997。
[XHTML 1.0] XHTML(tm) 1.0: The Extensible Hypertext Markup Language. W3C Recommendation. S. Pemberton, D. Raggett, et al. January 2000. http://www.w3.org/TR/2000/REC-xhtml1-20000126/
[XHTML 1.0] XHTML（登録商標）1.0：拡張可能ハイパーテキストマークアップ言語。 W3C勧告。 S.ペンバートン、D. Raggett、ら。 2000年1月http://www.w3.org/TR/2000/REC-xhtml1-20000126/
[XLink] XML Linking Language. W3C Recommendation. S. DeRose, E. Maler, D. Orchard. June 2001. http://www.w3.org/TR/2000/REC-xlink-20010627/
[XLinkの] XMLのリンク言語。 W3C勧告。 S. DeRose、E. MALER、D.オーチャード。 2001年6月http://www.w3.org/TR/2000/REC-xlink-20010627/
[XML] Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. October 2000. http://www.w3.org/TR/2000/REC-xml-20001006
[XML]拡張マークアップ言語（XML）1.0（Second Editionを）。 W3C勧告。 T.ブレイ、E. MALER、J.パオリ、C. M. Sperberg-マックイーン。 2000年10月http://www.w3.org/TR/2000/REC-xml-20001006
[XML-C14N] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[XML-C14N]ボイヤー、J.、 "標準的なXMLバージョン1.0"、RFC 3076、2001年3月。
[XML-Japanese] XML Japanese Profile. W3C Note. M. Murata April 2000 http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/
[XML-日本] XML日本語プロファイル。 W3Cに注意してください。 M.ムラタ2000年4月http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/
[XML-MT] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[XML-MT]ホワイトヘッド、E.およびM.村田、 "XMLのメディアタイプ"、RFC 2376、1998年7月。
[XML-ns] Namespaces in XML. W3C Recommendation. T. Bray, D. Hollander, A. Layman. January 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114
[XML-NS] XMLで名前空間。 W3C勧告。 T.ブレイ、D.オランダ、A.素人。 1999年1月http://www.w3.org/TR/1999/REC-xml-names-19990114
[XML-schema] XML Schema Part 1: Structures. W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part 2: Datatypes W3C Recommendation. P. Biron, A. Malhotra. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2- 20010502/
[XMLスキーマ] XMLスキーマパート1：構造。 W3C勧告。 D.ブナ、M.マロニー、N.メンデルゾーン、H.トンプソン。 2001年5月http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XMLスキーマパート2：データ型のW3C勧告。 P.ビロン、A.マルホトラ。 2001年5月http://www.w3.org/TR/2001/REC-xmlschema-2- 20010502 /
[XML-Signature-RD] Reagle, J., "XML Signature Requirements", RFC 2807, July 2000.
[XML-署名-RD] Reagle、J.、 "XML署名要件"、RFC 2807、2000年7月。
[XPath] XML Path Language (XPath) Version 1.0. W3C Recommendation. J. Clark, S. DeRose. October 1999. http://www.w3.org/TR/1999/REC-xpath-19991116
[XPathの] XMLパス言語（XPath）バージョン1.0。 W3C勧告。 J.クラーク、S. DeRose。 1999年10月http://www.w3.org/TR/1999/REC-xpath-19991116
[XPointer] XML Pointer Language (XPointer). W3C Working Draft. S. DeRose, R. Daniel, E. Maler. January 2001. http://www.w3.org/TR/2001/WD-xptr-20010108
【のXPointer] XMLポインタ言語（XPointerの）。 W3Cワーキングドラフト。 S. DeRose、R.ダニエル、E. MALER。 2001年1月http://www.w3.org/TR/2001/WD-xptr-20010108
[XSL] Extensible Stylesheet Language (XSL). W3C Proposed Recommendation. S. Adler, A. Berglund, J. Caruso, S. Deach, P. Grosso, E. Gutentag, A. Milowski, S. Parnell, J. Richman, S. Zilles. August 2001. http://www.w3.org/TR/2001/PR-xsl-20010828/
[XSL]拡張スタイルシート言語（XSL）。 W3Cは勧告を提案しました。 S.アドラー、A.ベルグルンド、J.カルーソ、S.ディーチ、P.グロッソ、E. Gutentag、A. Milowski、S.パーネル、J.リッチマン、S. Zilles。 2001年8月http://www.w3.org/TR/2001/PR-xsl-20010828/
[XSLT] XSL Transforms (XSLT) Version 1.0. W3C Recommendation. J. Clark. November 1999. http://www.w3.org/TR/1999/REC-xslt-19991116.html
[XSLT] XSL変換（XSLT）バージョン1.0。 W3C勧告。 J.クラーク。 1999年11月http://www.w3.org/TR/1999/REC-xslt-19991116.html
Authors' Addresses
著者のアドレス
Donald E. Eastlake 3rd Motorola, 20 Forbes Boulevard Mansfield, MA 02048 USA
ドナルドE.イーストレーク第3モトローラ、20フォーブス大通りマンスフィールド、MA 02048 USA
Phone: 1-508-851-8280 EMail: Donald.Eastlake@motorola.com
電話：1-508-851-8280 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
Full Copyright Statement
完全な著作権声明
Copyright (c) 2002 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
著作権（C）2002ザ・インターネット協会＆W3C（MIT、INRIA、慶應義塾大学）、すべての権利予約。
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機能のための基金は現在、インターネット協会によって提供されます。