Network Working Group J. Reagle
Request for Comments: 2807 W3C/MIT
Category: Informational July 2000
XML Signature Requirements
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
著作権（C）2000ザ・インターネット協会＆W3C（MIT、INRIA、慶應義塾大学）、すべての権利予約。
Abstract
抽象
This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.
この文書は、XMLデジタル署名仕様の設計原則、範囲、および要件を示します。彼らは署名シンタックス、データモデル、フォーマット、暗号処理、及び外部要件と連携に関係としては、要件を含みます。
Table of Contents
目次
1. Introduction .............................................. 1
2. Design Principles and Scope ............................... 2
3. Requirements .............................................. 4
3.1. Signature Data Model and Syntax .................... 4
3.2. Format ............................................. 5
3.3. Cryptography and Processing ........................ 5
3.4 Coordination ........................................ 5
4. Security Considerations ................................... 6
5. References ................................................ 6
6. Acknowledgements .......................................... 8
7. Author's Address .......................................... 8
8. Full Copyright Statement .................................. 9
The XML 1.0 Recommendation [XML] describes the syntax of a class of data objects called XML documents. The mission of this working group is to develop a XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiability.
XML 1.0勧告[XML]は、XML文書と呼ばれるデータオブジェクトのクラスの構文について説明します。このワーキンググループの使命は、コンピューティングのためのデジタルコンテンツの署名と手順を表し、そのような署名を検証するために使用されるXML構文を開発することです。署名は、データの整合性、認証、および/または非repudiabilityを提供します。
This document lists the design principles, scope, and requirements over three things: (1) the scope of work available to the WG, (2) the XML signature specification, and (3) applications that implement the specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. Those things that are required are designated as "must", those things that are optional are designated by "may", those things that are optional but recommended are designated as "should".
WGへの利用可能な作業の（1）の範囲、（2）XML署名の仕様、及び仕様を実装（3）アプリケーション：このドキュメントでは、三つの上に設計原則、範囲、および要件を示します。彼らは署名シンタックス、データモデル、フォーマット、暗号処理、及び外部要件と連携に関係としては、要件を含みます。 「必須」として指定されている必要とされるそれらのもの、で指定されているオプションであるそれらのものは、オプションですが、推奨それらのものは、「べき」として指定されている「こと」。
1. The specification must describe how to sign digital content, and XML content in particular. The XML syntax used to represent a signature (over any content) is described as an XML Signature. [Charter] 2. XML Signatures are generated from a hash over the canonical form of a signature manifest. (In this document we use the term manifest to mean a collection of references to the objects being signed. The specifications may use the terms manifest, package or other terms differently from this document while still meeting this requirement.) The manifest must support references to Web resources, the hash of the resource content (or its canonicalized form), and (optionally) the resource content type. [Brown, List(Solo)] Web resources are defined as any digital content that can be addressed using the syntax of XLink locator [XLink]). 3. The meaning of a signature is simple: The XML Signature syntax associates the content of resources listed in a manifest with a key via a strong one-way transformation. 1. The XML Signature syntax must be extensible such that it can support arbitrary application/trust semantics and assertion capabilities -- that can also be signed. [Charter(Requirement1&4), List(Bugbee, Solo)] 2. The WG is not chartered to specify trust semantics, but syntax and processing rules necessary for communicating signature validity (authenticity, integrity and non-repudiation). [Charter(Requirement1)] At the Chairs' discretion and in order to test the extensibility of the syntax, the WG may produce non-critical-path proposals defining common semantics (e.g., manifest, package, timestamps, endorsement, etc.) relevant to signed assertions about Web resources in a schema definition [XML, RDF] or link type definition [XLink]. Comment: A more formal definition of a signed resource is below. The notation is "definition(inputs):constraints" where definition evaluates as true for the given inputs and specified constraints. signed-resource(URI-of-resource, content, key, signature): (there was some protocol message at a specific time such that "GET(URI-of-resource) = content") AND (sign-doc(content, key, sig)) sign-doc(content, key, signature): signature is the value of a strong one-way transformation over content and key that yields content integrity/validity and/or key non-repudiability 4. The specification must not specify methods of confidentiality though the Working Group may report on the feasibility of such work in a future or rechartered activity. [List(Bugbee)] 5. The specification must only require the provision of key information essential to checking the validity of the cryptographic signature. For instance, identity and key recovery information might be of interest to particular applications, but they are not within the class of required information defined in this specification. [List(Reagle)] 6. The specification must define or reference at least one method of canonicalizing and hashing the signature syntax (i.e., the manifest and signature blocks). [Oslo] The specification must not specify methods of canonicalizing resource content [Charter], though it may specify security requirements over such methods. [Oslo] Such content is normalized by specifying an appropriate content C14N (canonicalization) algorithm [DOMHASH, XML-C14N]. Applications are expected to normalize application specific semantics prior to handing data to a XML Signature application or specify the necessary transformations for this process within the signature. [Charter] 7. XML Signature applications must be conformant with the specifications as follows: 1. XML-namespaces [XML-namespaces] within its own signature syntax. Applications may choose C14N algorithms which do or do not process namespaces within XML content. For instance, some C14N algorithms may opt to remove all namespace declarations, others may rewrite namespace declarations to provide for context independent declarations within every element. 2. XLink [Xlink] within its own signature syntax. For any resource identification beyond simple URIs (without fragment IDs) or fragmentIDs, applications must use XLink locators to reference signed resources. Signature applications must not embed or expand XLink references in signed content, though applications may choose C14N algorithms which provide this feature. 3. XML-Pointers [XPointer] within its own signature syntax. If applications reference/select parts of XML documents, they must use XML-Pointer within an XLink locator. [WS-list(1)] The WG may specify security requirements that constrain the operation of these dependencies to ensure consistent and secure signature generation and operation. [Oslo]
1.明細書は、特に、デジタルコンテンツ、およびXMLコンテンツに署名する方法を説明しなければなりません。 （任意のコンテンツに対する）署名を表すために使用されるXML構文は、XML署名として記載されています。 [チャーター] 2. XML署名は、署名マニフェストの正規形にわたってハッシュから生成されます。 （私たちが署名されているオブジェクトへの参照のコレクションを意味するマニフェスト用語を使用しています。それでも、この要件を満たしながら、仕様が異なり、この文書からマニフェスト、パッケージまたは他の用語用語を使用することができ、このドキュメントでは。）マニフェストは、への参照をサポートしている必要があります（必要に応じて）Webリソース、リソースコンテンツ（またはその正規化形態）のハッシュ、リソースのコンテンツタイプ。 [ブラウン、リスト（ソロ）] Webリソースは、XLinkのロケータ【のXLink]）の構文を使用して対処することができる任意のデジタルコンテンツとして定義されます。 3.署名の意味は単純である：XML署名シンタックスは、強い一方向の変換を介して、キーとマニフェストに列挙されたリソースのコンテンツを関連付けます。また、署名することができます - 1. XML署名の構文は、それが任意のアプリケーション/信頼のセマンティクスとアサーション機能をサポートできるように拡張可能でなければなりません。 [憲章（Requirement1＆4）、リスト（Bugbee、ソロ）] 2 WGは、署名妥当性（真正性、完全性および否認防止）を通信するために必要な信頼セマンティクスが、構文および処理規則を指定するためにチャーターされていません。 [憲章（Requirement1）]議長の裁量でと構文の拡張性をテストするために、WGは共通のセマンティクスを定義する非クリティカル・パス提案を生み出す（例えば、マニフェスト、パッケージ、タイムスタンプ、裏書、など）、関連しますスキーマ定義でのWebリソースに関する署名アサーションに[XML、RDF]またはリンク型定義[XLinkの]。コメント：署名リソースのより正式な定義は以下の通りです。定義は、所与の入力および指定された制約のために真と評価：表記は、「制約の定義（入力）」です。署名されたリソース（URI-のリソース、コンテンツ、キー、署名）：（いくつかのプロトコル・メッセージは、「（URI-のリソース）を取得=コンテンツ」という特定の時間に存在した）AND（（コンテンツを、ドキュメントに署名キー、SIG）） - ログインDOC（コンテンツ、キー、署名）：署名は、コンテンツの完全性/有効性及び/又はキー非repudiability 4が得られるコンテンツと鍵オーバー強い一方向変換の値で指定しない必要ワーキンググループは将来、もしくは別の活動でこのような作業の実現可能性について報告するかもしれないが、機密性の方法を指定します。仕様書5. [一覧（Bugbeeは）]のみ暗号署名の有効性をチェックするために不可欠の鍵情報の提供を要求する必要があります。たとえば、アイデンティティとキー回復情報は、特定のアプリケーションへの関心のかもしれないが、彼らはこの仕様で定義された必要な情報のクラス内ではありません。 [リスト（Reagle）] 6仕様を定義または参照canonicalizingの少なくとも一つの方法を、署名シンタックス（すなわち、マニフェストおよび署名ブロック）をハッシュしなければなりません。それは、このような方法に比べてセキュリティ要件を指定するかもしれませんが、[オスロ]仕様は、canonicalizingリソースコンテンツ[チャーター]の方法を指定してはなりません。 【オスロ】このようなコンテンツは、適切なコンテンツC14N（正規化）アルゴリズム[DOMHASH、XML-C14N]を指定することによって正規化されます。アプリケーションは、XML署名アプリケーションに渡すデータに先立ってアプリケーション固有のセマンティクスを正規化または署名内のこのプロセスのために必要な変換を指定することが期待されます。それ自身の署名シンタックス内1. XML-名前空間[XML-名前空間]を以下のように[チャーター] 7 XML署名アプリケーションは、仕様に適合しなければなりません。アプリケーションは、実行するか、XMLコンテンツ内の名前空間を処理しませんC14Nアルゴリズムを選択することができます。例えば、いくつかのC14Nアルゴリズムは、他の人がすべての要素内のコンテキストの独立宣言を提供するために、名前空間宣言を書き換えることが、すべての名前空間宣言を削除することを選ぶことができます。それ自身の署名シンタックス内の2のXLink [XLINK]。簡単のURI（フラグメントのIDなし）またはfragmentIDs越えた任意のリソース識別のために、アプリケーションが署名されたリソースを参照するためのXLinkロケータを使用しなければなりません。アプリケーションは、この機能を提供C14Nアルゴリズムを選択するかもしれませんが署名アプリケーションは、署名した内容でのXLink参照を埋め込んだり、拡張してはいけません。それ自身の署名シンタックス内の3 XML-ポインタ[XPointerの]。アプリケーションは、XML文書の/選択部分を参照する場合は、XLinkのロケータ内XML-ポインターを使用する必要があります。 [WS-リストは、（1）] WGは、一貫して安全な署名生成と操作を保証するために、これらの依存関係の動作を制約するセキュリティ要件を指定することができます。 [オスロ]
8. XML Signatures must be developed as part of the broader Web design philosophy of decentralization, URIs, Web data, modularity/layering/extensibility, and assertions as statements about statements. [Berners-Lee, WebData] In this context, existing cryptographic provider (and infrastructure) primitives should be taken advantage of. [List(Solo)]
8. XML署名は、より広範なWebデザイン、地方分権の理念、URIを、Webデータ、モジュール化/レイヤー/拡張性、およびステートメントについての声明としてアサーションの一部として開発されなければなりません。 [バーナーズ - リー、WEBDATA]この文脈では、既存の暗号化サービスプロバイダ（およびインフラストラクチャ）プリミティブはの利点を取らなければなりません。 [リスト（ソロ）]
1. XML Signature data structures must be based on the RDF data model [RDF] but need not use the RDF serialization syntax. [Charter] 2. XML Signatures apply to any resource addressable by a locator -- including non-XML content. XML Signature referents are identified with XML locators (URIs or fragments) within the manifest that refer to external or internal resources (i.e., network accessible or within the same XML document/package). [Berners-Lee, Brown, List(Vincent), WS, XFDL] 3. XML Signatures must be able to apply to a part or totality of a XML document. [Charter, Brown] Comment: A related requirement under consideration is requiring the specification to support the ability to indicate those portions of a document one signs via exclusion of those portions one does not wish to sign. This feature allows one to create signatures that have document closure [List(Boyer(1)], retain ancestor information, and retain element order of non-continuous regions that must be signed. We are considering implementing this requirement via (1) a special <dsig:exclude> element, (2) an exclude list accompanying the resource locator, or (3) the XML-Fragment or XPointer specifications -- or a requested change to those specifications if the functionality is not available. See List(Boyer(1,2)) for further discussion of this issue. 4. Multiple XML Signatures must be able to exist over the static content of a Web resource given varied keys, content transformations, and algorithm specifications (signature, hash, canonicalization, etc.). [Charter, Brown] 5. XML Signatures are first class objects themselves and consequently must be able to be referenced and signed. [Berners-Lee] 6. The specification must permit the use of varied digital signature and message authentication codes, such as symmetric and asymmetric authentication schemes as well as dynamic agreement of keying material. [Brown] Resource or algorithm identifier are a first class objects, and must be addressable by a URI. [Berners-Lee] 7. XML Signatures must be able to apply to the original version of an included/encoded resource. [WS-list (Brown/Himes)]
1. XML署名データ構造は、[RDF] RDFデータモデルに基づいている必要がありますが、RDFのシリアライゼーション構文を使用する必要はありません。非XMLコンテンツを含む - [チャーター] 2. XML署名は、ロケータによって任意のリソースアドレス指定に適用されます。 XML署名の対象（すなわち、ネットワークアクセス可能な又は同一のXML文書/パッケージ内）、外部または内部のリソースを参照するマニフェスト内のXMLロケータ（URIのまたはフラグメント）で識別されます。 [バーナーズ=リー、ブラウン、リスト（ヴィンセント）、WS、XFDL] 3. XML署名は、XML文書の一部または全体に適用することができなければなりません。 [チャーター、ブラウン]コメント：検討中の関連する要件は、1つの署名を望まないそれらの部分の排除を介して、文書1つの徴候の部分を指示する能力をサポートするための仕様を必要とされています。この機能は、1つの文書の閉鎖を持って署名を作成することを可能にする[リスト（ボイヤー（1）]、祖先の情報を保持し、我々は、を介してこの要求を実現する検討している署名されなければならない非連続領域の要素の順序を保持する（1）スペシャル<DSIG：除外>、要素（2）ANリストリソースロケータを伴う、または（3）XMLフラグメントもしくはXPointerの仕様除外 - （（ボイヤーの機能が利用できない場合や、それらの仕様に要求された変更を一覧を参照してください。 1,2））この問題のさらなる議論のために。4.複数のXML署名はウェブリソースの静的なコンテンツ上に与えられた変化キー、コンテンツ変換、およびアルゴリズムの仕様（署名、ハッシュ、正規化など）が存在することができなければなりません[チャーター、ブラウン] 5 XML署名が最初のクラスであるオブジェクト自体、その結果、参照と署名することができなければならない。[バーナーズ - リー] 6仕様変化デジタル署名およびメッセージ認証コードの使用を許可しなければならない、などsymmeトリCおよび非対称認証スキームだけでなく、材料をキーイングの動的な合意。 【ブラウン】リソースまたはアルゴリズム識別子はファーストクラスのオブジェクトであり、URIによってアドレス可能でなければなりません。 [バーナーズ - リー] 7. XML署名が含まれ/符号化されたリソースの元のバージョンに適用することができなければなりません。 [WS-リスト（ブラウン/ Himes）]
1. An XML Signature must be an XML element (as defined by production 39 of the XML1.0 specification. [XML]) 2. When XML signatures are placed within a document the operation must preserve (1) the document's root element tag as root and (2) the root's descendancy tree except for the addition of signature element(s) in places permitted by the document's content model. For example, an XML form, when signed, should still be recognizable as a XML form to its application after it has been signed. [WS-summary] 3. XML Signature must provide a mechanism that facilitates the production of composite documents -- by addition or deletion -- while preserving the signature characteristics (integrity, authentication, and non-repudiability) of the consituent parts. [Charter, Brown, List(Bugbee)] 4. An important use of XML Signatures will be detached Web signatures. However, signatures may be embedded within or encapsulate XML or encoded content. [Charter] This WG must specify a simple method of packaging and encapsulation if no W3C Recommendation is available.
1. XML署名は、（XML1.0仕様の製造39によって定義される。[XML]）XML要素でなければならない2. XML署名が文書内に配置されている場合の動作として、（1）文書のルート要素タグを保持しなければなりません文書の内容モデルによって許可場所に署名要素（単数または複数）の添加を除いルート及び（2）ルートのdescendancy木。それが署名された後、例えば、XML形式は、署名された場合、まだアプリケーションにXML形式として認識すべきです。 [WS-要約]複合ドキュメントの生産を容易に機構を提供しなければならない。3. XML署名 - 付加または欠失によって - consituentパーツの署名特性（整合性、認証、および非repudiability）を維持しながら。 [憲章、ブラウン、リスト（Bugbee）] 4. XML署名の重要な使用は、Web署名をデタッチします。ただし、署名は、内部に埋め込まれた、またはXMLまたはエンコードされたコンテンツをカプセル化することができます。何のW3C勧告が利用できない場合は、[チャーター]このWGは、包装やカプセル化の簡単な方法を指定する必要があります。
1. The specification must permit arbitrary cryptographic signature and message authentication algorithms, symmetric and asymmetric authentication schemes, and key agreement methods. [Brown] 2. The specification must specify at least one mandatory to implement signature canonicalization, content canonicalization, hash, and signature algorithm. 3. In the event of redundant attributes within the XML Signature syntax and relevant cryptographic blobs, XML Signature applications prefer the XML Signature semantics. Comment: Another possibility is that an error should be generated, however it isn't where a conflict will be flagged between the various function and application layers regardless. 4. The signature design and specification text must not permit implementers to erroneously build weak implementations susceptible to common security weaknesses (such as as downgrade or algorithm substitution attacks).
1.仕様は、任意の暗号署名およびメッセージ認証アルゴリズム、対称および非対称認証スキーム、及びキー合意の方法を可能にしなければなりません。 【ブラウン】2署名正規化、コンテンツ正規化、ハッシュ、および署名アルゴリズムを実装するために必須の少なくとも一つを指定しなければならない仕様。 3. XML署名構文内の冗長な属性および関連する暗号ブロブのイベントでは、XML署名アプリケーションは、XML署名セマンティクスを好みます。コメント：別の可能性は、競合に関係なく、様々な機能とアプリケーション層の間にフラグを立てされる場所がそうでないと、エラーが発生しなければならないということです。 4.署名の設計と仕様テキストが誤って（たとえば、ダウングレードまたはアルゴリズムの代替攻撃などのような）一般的なセキュリティ上の弱点の影響を受けやすい弱い実装を構築するために実装を許可してはいけません。
1. The XML Signature specification should meet the requirements of the following applications: 1. Internet Open Trading Protocol v1.0 [IOTP] 2. Financial Services Mark Up Language v2.0 [Charter] 3. At least one forms application [XFA, XFDL]
1. XML署名仕様は、以下のアプリケーションの要件を満たす必要があります。1.インターネットオープン取引プロトコルv1.0の[IOTP] 2.金融サービスマークアップ言語v2.0の[チャーター]前記少なくとも1つのフォームアプリケーション[XFA、 XFDL]
2. To ensure that all requirements within this document are adequately addressed, the XML Signature specification must be reviewed by a designated member of the following communities: 1. XML Syntax Working Group: canonicalization dependencies. [Charter] 2. XML Linking Working Group: signature referents. [Charter] 3. XML Schema Working Group: signature schema design. [Charter] 4. Metadata Coordination Group: data model design. [Charter] 5. W3C Internationalization Interest Group: [AC Review] 6. XML Package Working Group: signed content in/over packages. 7. XML Fragment Working Group: signing portions of XML content. Comment: Members of the WG are very interested in signing and processing XML fragments and packaged components. Boyer asserts that [XML-fragment] does not "identify non-contiguous portions of a document in such a way that the relative positions of the connected components is preserved". Packaging is a capability critical to XML Signature applications, but it is clearly dependent on clear trust/semantic definitions, package application requirements, and even cache-like application requirements. It is not clear how this work will be addressed.
2.このドキュメント内のすべての要件が適切に対処されていることを確認するには、XML署名仕様は、下記のコミュニティの指定されたメンバーによって検討されている必要があります。1. XML構文ワーキンググループ：正規の依存関係。 [チャーター] 2. XMLリンクワーキンググループ：署名の対象。 [チャーター] 3. XMLスキーマワーキンググループ：署名スキーマの設計。 [チャーター] 4.メタデータの調整グループ：データモデルの設計。 [チャーター] 5. W3C国際化インタレストグループ：[ACレビュー] 6. XMLパッケージワーキンググループは：中/パッケージを介してコンテンツに署名しました。 7. XMLフラグメントワーキンググループ：XMLコンテンツの部分に署名します。コメント：WGのメンバーは、署名と処理XMLフラグメントとパッケージコンポーネントに非常に興味を持っています。ボイヤーは、[XML断片は「連結成分の相対的な位置が維持されるように文書の非隣接部分を識別しない」と主張します。パッケージングは、XML署名アプリケーションにとって重要な機能ですが、それは明らかに明確な信頼/セマンティック定義、パッケージアプリケーションの要件、さらにはキャッシュのようなアプリケーションの要件に依存しています。この作品に対処する方法は明らかではありません。
This document lists XML Digital Signature requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. In that context much of this document is about security.
彼らは署名シンタックス、データモデル、フォーマット、暗号処理、および外部の要件との連携に関連してこの文書は、XMLデジタル署名要件を示します。その意味で、この文書の多くは、セキュリティに関するものです。
AC Review Misha Wolf. "The Charter should include the I18N WG in the section on `Coordination with Other Groups'", http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007.html
ACレビューミーシャウルフ。 「憲章は他のグループとの連携 `のセクションでI18N WGを含むべきである」、http://lists.w3.org/Archives/Team/xml-dsig-review/1999May/0007.html
Berners-Lee Axioms of Web Architecture: URIs. http://www.w3.org/DesignIssues/Axioms.html Web Architecture from 50,000 feet http://www.w3.org/DesignIssues/Architecture.html
Webアーキテクチャのバーナーズ=リー公理：URIを。 http://www.w3.org/DesignIssues/Axioms.html5万フィートからのWebアーキテクチャhttp://www.w3.org/DesignIssues/Architecture.html
Brown-XML-DSig Work in Progress. Digital Signatures for XML http://www.w3.org/Signature/Drafts/xmldsig-signature-990618.html
ブラウン-XML-DSIG進行中の作業。 XMLのためのデジタル署名http://www.w3.org/Signature/Drafts/xmldsig-signature-990618.html
Charter XML Signature (xmldsig) Charter. http://www.w3.org/1999/05/XML-DSig-charter-990521.html
チャーターXML署名（XMLDSIG）チャーター。 http://www.w3.org/1999/05/XML-DSig-charter-990521.html
DOMHASH Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.
DOMHASH丸山、H.、田村、K.およびN. Uramoto、 "DOMのためのダイジェスト値（DOMHASH）"、RFC 2803、2000年4月。
FSML FSML 1.5 Reference Specification http://www.echeck.org/library/ref/fsml-v1500a.pdf
FSML FSML 1.5リファレンス仕様http://www.echeck.org/library/ref/fsml-v1500a.pdf
Infoset-Req XML Information Set Requirements Note. http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html
インフォセット-REQ XML情報セットの要件に注意してください。 http://www.w3.org/TR/1999/NOTE-xml-infoset-req-19990218.html
IOTP Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
IOTPバーデット、D.、 "インターネットオープン取引プロトコル - IOTPバージョン1.0"、RFC 2801、2000年4月。
IOTP-DSig Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.
IOTP-DSIGダビッドソン、K.とY. Kawatsura、RFC 2802、2000年4月 "v1.0のインターネットオープン取引プロトコル（IOTP）のデジタル署名"。
Oslo Minutes of the XML Signature WG Sessions at IETF face-to-face meeting in Oslo.
オスロのIETF対面会議でXML署名WGセッションのオスロ分。
RDF RDF Schema http://www.w3.org/TR/1999/PR-rdf-schema-19990303 RDF Model and Syntax http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
RDF RDFスキーマhttp://www.w3.org/TR/1999/PR-rdf-schema-19990303 RDFモデルとシンタックスhttp://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Signature WG List http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/
署名WGレターhttp://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/
URI Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. http://www.ietf.org/rfc/rfc2396.txt
URIバーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月http://www.ietf.org/rfc/rfc2396.txt
WS (list, summary) XML-DSig '99: The W3C Signed XML Workshop http://www.w3.org/DSig/signed-XML99/ http://www.w3.org/DSig/signed-XML99/summary.html
WS（リスト、要約）XML-DSIG '99：W3C XML署名のワークショップhttp://www.w3.org/DSig/signed-XML99/ http://www.w3.org/DSig/signed-XML99/summary .htmlを
XLink XML Linking Language http://www.w3.org/1999/07/WD-xlink-19990726
XLinkのXMLリンク言語http://www.w3.org/1999/07/WD-xlink-19990726
XML Extensible Markup Language (XML) Recommendation. http://www.w3.org/TR/1998/REC-xml-19980210
XML拡張マークアップ言語（XML）勧告。 http://www.w3.org/TR/1998/REC-xml-19980210
XML-C14N XML Canonicalization Requirements. http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605
XML-C14N XMLの正規化の要件。 http://www.w3.org/TR/1999/NOTE-xml-canonical-req-19990605
XFA XML Forms Architecture (XFA) http://www.w3.org/Submission/1999/05/
XFA XMLフォームアーキテクチャ（XFA）http://www.w3.org/Submission/1999/05/
XFDL Extensible Forms Description Language (XFDL) 4.0 http://www.w3.org/Submission/1998/16/
XFDL拡張は記述言語（XFDL）4.0 http://www.w3.org/Submission/1998/16/フォーム
XML-Fragment XML-Fragment Interchange http://www.w3.org/1999/06/WD-xml-fragment-19990630.html
XML-フラグメントXMLフラグメントインターチェンジhttp://www.w3.org/1999/06/WD-xml-fragment-19990630.html
XML-namespaces Namespaces in XML http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-名前空間XML名前空間でhttp://www.w3.org/TR/1999/REC-xml-names-19990114
XML-schema XML Schema Part 1: Structures http://www.w3.org/1999/05/06-xmlschema-1/ XML Schema Part 2: Datatypes http://www.w3.org/1999/05/06-xmlschema-2/
XMLスキーマのXMLスキーマパート1：構造http://www.w3.org/1999/05/06-xmlschema-1/ XMLスキーマパート2：データ型http://www.w3.org/1999/05/06 -xmlschema-2 /
XPointer XML Pointer Language (XPointer) http://www.w3.org/1999/07/WD-xptr-19990709
XPointerのXMLポインタ言語（XPointerの）http://www.w3.org/1999/07/WD-xptr-19990709
WebData Web Architecture: Describing and Exchanging Data. http://www.w3.org/1999/04/WebData
WEBDATAのWebアーキテクチャ：記述とデータの交換。 http://www.w3.org/1999/04/WebData
This document was produced as a collaborative work item of the XML Signature (xmldsig) Working Group.
この文書は、XML署名（XMLDSIG）ワーキンググループの共同作業項目として生成しました。
Joseph M. Reagle Jr., W3C XML Signature Co-Chiar Massachusetts Institute of Technology Laboratory for Computer Science W3C, NE43-350 545 Technology Square Cambridge, MA 02139
ジョセフM. Reagleジュニア、W3C XML署名コンピュータサイエンスW3C、NE43-350 545テクノロジースクエアケンブリッジ、MA 02139のための技術研究所の共同Chiarマサチューセッツ工科大学
Phone: 1.617.258.7621 EMail: reagle@w3.org URL: http://www.w3.org/People/Reagle
電話番号：1.617.258.7621メールアドレス：reagle@w3.org URL：http://www.w3.org/People/Reagle
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
著作権（C）2000ザ・インターネット協会＆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機能のための基金は現在、インターネット協会によって提供されます。