[要約] RFC 2807は、XML署名の要件を定義する文書であり、デジタル署名の標準化を目的としています。このRFCは、XML文書やデータオブジェクトに対する署名の生成と検証に関する要件を明確にし、Webサービスや電子商取引などの分野でのセキュリティ保証を強化することを目指しています。関連するRFCには、XML署名構文と処理を定義するRFC 3275などがあります。RFC 2807は、セキュリティ技術の標準化を進める上での基礎となる文書の一つです。
Network Working Group J. Reagle
Request for Comments: 2807 W3C/MIT
Category: Informational July 2000
XML Signature Requirements
XML署名要件
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.
Copyright（c）2000 The Internet Society＆W3C（MIT、INRIA、KEIO）、All Rights Reserved。
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構文を開発することです。署名は、データの整合性、認証、および/または非和解性を提供します。
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".
このドキュメントには、3つの事項にわたる設計原則、範囲、および要件がリストされています。（1）WGが利用できる作業の範囲、（2）XML署名仕様、および（3）仕様を実装するアプリケーション。署名構文、データモデル、形式、暗号化処理、外部要件と調整に関連する要件が含まれます。必要なものは「必須」として指定されており、オプションのものは「5月」によって指定され、オプションであるが推奨されるものは「必要」として指定されます。
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リソース、リソースコンテンツ（またはその標準化された形式）のハッシュ、および（オプションで）リソースコンテンツタイプ。[Brown、List（Solo）] Webリソースは、Xlink Locator [Xlink]）の構文を使用してアドレス指定できるデジタルコンテンツとして定義されます。3.署名の意味は単純です。XML署名構文は、強力な一方向変換を介してキーとともにマニフェストにリストされているリソースのコンテンツを関連付けます。1. XML署名構文は、署名することもできる任意のアプリケーション/信頼セマンティクスとアサーション機能をサポートできるように拡張可能でなければなりません。[Charter（composement1＆4）、list（bugbee、solo）] 2. WGは、信頼セマンティクスを指定するためにチャーターされていませんが、署名の妥当性（信頼性、完全性、非繰り返し）を伝えるために必要な構文と処理ルール。[charter（complection1）]椅子の裁量で、および構文の拡張性をテストするために、WGは共通のセマンティクス（例えば、マニフェスト、パッケージ、タイムスタンプ、承認など）を定義する非批判的なパス提案を作成する場合があります。スキーマ定義[XML、RDF]またはリンクタイプ定義[XLINK]でWebリソースに関するアサーションに署名します。コメント：署名されたリソースのより正式な定義は以下にあります。表記は「定義（入力）：制約」です。ここで、定義は指定された入力と指定された制約に対して真であると評価します。Signed-Resource（Uri-Of-Resource、Content、Key、Signature）：（「Get（Uri-of-Resource）= content」）と（sign-doc（content、）など、特定の時間にプロトコルメッセージがありました。key、sig））sign-doc（コンテンツ、キー、署名）：署名は、コンテンツに対する強力な一方向変換の価値と、コンテンツの完全性/妥当性および/またはキーの非再構成をもたらすキー4.ワーキンググループは、将来または充電された活動におけるそのような作業の実現可能性について報告する場合がありますが、機密性の方法を指定します。[list（bugbee）] 5.仕様には、暗号化署名の有効性をチェックするために不可欠な重要な情報の提供のみが必要です。たとえば、IDおよび主要な回復情報は特定のアプリケーションにとって興味深い場合がありますが、これらはこの仕様で定義されている必要な情報のクラス内ではありません。[list（reagle）] 6.仕様は、署名構文（つまり、マニフェストおよび署名ブロック）を正規化およびハッシュする少なくとも1つの方法を定義または参照する必要があります。[OSLO]仕様は、リソースコンテンツを正規化する方法[Charter]を指定してはなりませんが、このような方法でセキュリティ要件を指定できます。[Oslo]そのような含有量は、適切なコンテンツC14N（Canonicalization）アルゴリズム[Domhash、XML-C14N]を指定することにより正規化されます。アプリケーションは、データをXML署名アプリケーションに引き渡す前に、アプリケーション固有のセマンティクスを正規化するか、署名内のこのプロセスに必要な変換を指定することが期待されます。[チャーター] 7. XML署名アプリケーションは、次のように仕様に準拠する必要があります。1。XML-NamesSpaces [XML-NamesSpaces]独自の署名構文内。アプリケーションは、XMLコンテンツ内の名前空間を処理または処理しないC14Nアルゴリズムを選択する場合があります。たとえば、一部のC14Nアルゴリズムは、すべての名前空間宣言を削除することを選択する場合があり、他のC14Nはすべての要素内でコンテキスト独立宣言を提供するために名前空間宣言を書き直すことができます。2. Xlink [Xlink]独自の署名構文内。単純なuris（フラグメントIDなし）またはfragmentidsを超えたリソース識別の場合、アプリケーションはxlinkロケーターを使用して署名されたリソースを参照する必要があります。署名アプリケーションは、署名されたコンテンツにXlink参照を埋め込んだり展開したりしてはなりませんが、アプリケーションはこの機能を提供するC14Nアルゴリズムを選択する場合があります。3. XML-Pointers [XPointer]独自の署名構文内。XMLドキュメントの部分を参照/選択する場合、Xlinkロケーター内のXML-Pointerを使用する必要があります。[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の署名は、地方分権化、URIS、Webデータ、モジュール性/階層化/拡張性、およびステートメントに関するステートメントとしてのアサーションのより広範なWebデザイン哲学の一部として開発する必要があります。[Berners-Lee、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シリアル化構文を使用する必要はありません。[チャーター] 2. XML署名は、XML以外のコンテンツを含むロケーターがアドレス指定できる任意のリソースに適用されます。XML署名指示対象は、外部リソースまたは内部リソース（つまり、ネットワークアクセス可能または同じXMLドキュメント/パッケージ内）を参照するマニフェスト内のXMLロケーター（URIまたはフラグメント）で識別されます。[Berners-Lee、Brown、List（Vincent）、WS、XFDL] 3. XML署名は、XMLドキュメントの一部または全体に適用できる必要があります。[チャーター、ブラウン]コメント：検討中の関連する要件は、ドキュメントのこれらの部分を示す能力をサポートすることを要求することです。この機能により、ドキュメントクロージャー[リスト（ボイヤー（1）]]がある署名を作成し、祖先情報を保持し、署名する必要がある非連続地域の要素順序を保持できます。<DSIG：exclude>要素、（2）リソースロケーターに付随する除外リスト、または（3）XML-FRAGMENTまたはXPOINTER仕様 - または機能が利用できない場合はそれらの仕様の要求された変更。1,2））この問題のさらなる議論のために。4。さまざまなキー、コンテンツ変換、およびアルゴリズム仕様（署名、ハッシュ、標準化など）が与えられたWebリソースの静的コンテンツに複数のXML署名が存在する必要があります。。[チャーター、ブラウン] 5. XML署名はファーストクラスのオブジェクト自体であり、その結果、参照して署名することができなければなりません。対称および非対称認証スキームとキーイング材料の動的な一致。[茶色]リソースまたはアルゴリズム識別子はファーストクラスのオブジェクトであり、URIがアドレス指定できる必要があります。[Berners-Lee] 7. XML署名は、付属/エンコードされたリソースの元のバージョンに適用できる必要があります。[ws-list（brown/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署名はXML要素でなければなりません（XML1.0仕様の生産39で定義されています。[XML]）2。XML署名がドキュメント内に配置されている場合、操作は操作を保持する必要があります（1）ドキュメントのルート要素タグはルートとして、（2）ドキュメントのコンテンツモデルで許可されている場所に署名要素を追加することを除き、ルートの子孫ツリー。たとえば、XMLフォームは、署名時に、署名後もXMLフォームとしてXMLフォームとして認識できる必要があります。[WS-Summary] 3. XML署名は、構成部品の署名特性（整合性、認証、および非整合性）を維持しながら、追加または削除によって複合ドキュメントの生産を促進するメカニズムを提供する必要があります。[Charter、Brown、List（Bugbee）] 4. XML署名の重要な使用は、Webシグネチャーの分離です。ただし、署名は、XMLまたはエンコードされたコンテンツに埋め込まれたり、カプセル化されたりする場合があります。[チャーター]このWGは、W3Cの推奨が利用できない場合は、パッケージングとカプセル化の簡単な方法を指定する必要があります。
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.仕様は、署名の標準化、コンテンツの標準化、ハッシュ、および署名アルゴリズムを実装するために少なくとも1つの必須を指定する必要があります。3. XML署名構文および関連する暗号ブロブ内に冗長属性が発生した場合、XML署名アプリケーションはXML署名セマンティクスを好みます。コメント：もう1つの可能性は、エラーを生成する必要があることですが、さまざまな関数レイヤーとアプリケーションレイヤーの間に競合がフラグを立てる場所ではありません。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 [チャーター] 3.少なくとも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構文ワーキンググループ：Canonicalization依存関係。[チャーター] 2. XMLリンクワーキンググループ：署名指示対象。[チャーター] 3. XMLスキーマワーキンググループ：署名スキーマ設計。[チャーター] 4.メタデータ調整グループ：データモデル設計。[チャーター] 5. W3C国際化利益グループ：[ACレビュー] 6. XMLパッケージワーキンググループ：パッケージ内/オーバーパッケージに署名されたコンテンツ。7. XMLフラグメントワーキンググループ：XMLコンテンツの一部の署名。コメント：WGのメンバーは、XMLフラグメントとパッケージ化されたコンポーネントの署名と処理に非常に興味があります。Boyerは、[XML-Fragment]は、「接続されたコンポーネントの相対的な位置が保存されるように、文書の非連続部分を識別しない」と主張しています。パッケージングは、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レビューMisha Wolf。「チャーターには、「他のグループとの調整」に関するセクションに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アーキテクチャのBerners-Lee公理：uris。http://www.w3.org/designissues/axioms.html Webアーキテクチャ50,000フィート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
Brown-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 Maruyama、H.、Tamura、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
InfoSet-REQ XML情報設定要件注。http://www.w3.org/tr/1999/note-xml-infoset-req-1990218.html
IOTP Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
IOTP Burdett、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 Davidson、K。およびY. Kawatsura、「V1.0インターネットオープントレーディングプロトコル（IOTP）のデジタル署名」、RFC 2802、2000年4月。
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 Schema 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 Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。http：//www.ietf.org/rfc/rfc2396.txt
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/ummary.html
XLink XML Linking Language http://www.w3.org/1999/07/WD-xlink-19990726
Xlink XMLリンク言語http://www.w3.org/1999/07/wd-xlink-1990726
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 CanOnicalization要件。http://www.w3.org/tr/1999/note-xml-canonical-req-1990605
XFA XML Forms Architecture (XFA) http://www.w3.org/Submission/1999/05/
XFA XML Forms Architecture（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-fragment xml-fragment Interchange http://www.w3.org/1999/06/wd-xml-fragment-1990630.html
XML-namespaces Namespaces in XML http://www.w3.org/TR/1999/REC-xml-names-19990114
xml-namespaces 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-Schema XML Schemaパート1：構造http://www.w3.org/1999/05/06-xmlschema-1/ xmlスキーマパート2：データタイプhttp://www.w3.org/1999/05/05/06-xmlschema-2/
XPointer XML Pointer Language (XPointer) http://www.w3.org/1999/07/WD-xptr-19990709
Xpointer XML Pointer Language（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
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
Phone: 1.617.258.7621
EMail: reagle@w3.org
URL: http://www.w3.org/People/Reagle
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
Copyright（c）2000 The Internet Society＆W3C（MIT、INRIA、KEIO）、All Rights Reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。