RFC2807 日本語訳
2807 XML Signature Requirements. J. Reagle. July 2000. (Format: TXT=21973 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Reagle Request for Comments: 2807 W3C/MIT Category: Informational July 2000
Reagleがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2807年のW3C/MITカテゴリ: 情報の2000年7月
XML Signature Requirements
XML署名要件
Status of this Memo
この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インターネット協会とW3C(MIT、INRIA、慶応)、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 Digital Signature仕様のための設計原理、範囲、および要件をリストアップします。 署名構文、データモデル、形式、暗号の処理、外部の要件、およびコーディネートに関連するとき、それは要件を含んでいます。
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
1. 序論… 1 2. プリンシプルズと範囲を設計してください… 2 3. 要件… 4 3.1. 署名データモデルと構文… 4 3.2. 形式… 5 3.3. 暗号と処理… 5 3.4コーディネート… 5 4. セキュリティ問題… 6 5. 参照… 6 6. 承認… 8 7. 作者のアドレス… 8 8. 完全な著作権宣言文… 9
1. Introduction
1. 序論
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.
XML1.0Recommendation[XML]はXMLドキュメントと呼ばれるデータ・オブジェクトのクラスの構文について説明します。 このワーキンググループの任務はそのような署名を計算して、確かめるためのデジタル・コンテンツと手順に署名を表すのに使用されるXML構文を開発することになっています。 署名はデータ保全、認証、そして/または、非repudiabilityを提供するでしょう。
Reagle Informational [Page 1] RFC 2807 XML Signature Requirements July 2000
[1ページ]RFC2807XML署名要件2000年7月の情報のReagle
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)アプリケーション。 署名構文、データモデル、形式、暗号の処理、外部の要件、およびコーディネートに関連するとき、それは要件を含んでいます。 必要であるそれらのものは“must"として指定されて、それらの任意のものは“may"によって指定されて、それらの任意の、しかし、お勧めであることのものは“should"として指定されます。
2. Design Principles and Scope
2. 設計原理と範囲
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))
1. 仕様はデジタル・コンテンツ、およびXMLが特に内容であると署名する方法を説明しなければなりません。 署名(どんな内容の上の)を表すのに使用されるXML構文はXML Signatureとして記述されています。 [憲章。]2 XML Signaturesは署名顕現の標準形でハッシュから生成されます。 (本書では私たちは、署名されるオブジェクトの参照の収集を意味するのに顕現という用語を使用します。 仕様はまだこの必要条件を満たしている間、用語顕現、パッケージまたは他の用語をこのドキュメントと異なって使用するかもしれません。) 顕現はウェブリソース、資源含有量のハッシュ(または、canonicalizedフォーム)、および(任意に)リソースcontent typeの参照をサポートしなければなりません。 [ブラウン、List(独奏]ウェブリソースはXLinkロケータ[XLink]の構文を使用することで扱うことができるどんなデジタル・コンテンツとも定義されます。) 3. 署名の意味は簡単です: XML Signature構文は強い一方向変換で顕現でリストアップされたリソースの内容をキーに関連づけます。 1. XML Signature構文は、任意のアプリケーション/信頼が意味論と主張能力また、(署名することができる)であるとサポートすることができるように広げることができなければなりません。 [(Requirement1と4)をチャーターしてください、そして、2を記載してください(一人で生活Bugbee]。 WGは信頼意味論を指定するためにチャーターされませんが、構文と処理は署名の正当性(信憑性、保全、および非拒否)を伝えるのに必要な状態で統治されます。 [Chairsの裁量で(Requirement1]をチャーターしてください、構文の伸展性をテストするには、WGは図式定義[XML、リモート・データ・ファシリティ]でウェブリソースに関して署名している主張に関連している一般的な意味論(例えば、顕現、パッケージ、タイムスタンプ、裏書きなど)を定義する非クリティカルパス提案を起こすか、または型定義[XLink]をリンクするかもしれません。 コメント: 署名しているリソースの、より正式な定義が以下にあります。 記法は、定義が付与のために同じくらい本当に入力を評価するところの「定義(入力): 規制」であり、規制署名しているリソース(リソースのURI、満足していて、主要な署名)を指定しました: (特定の時に、何らかのプロトコルメッセージがあったので、「GET(リソースのURI)は内容と等しいです」) AND(サイン-doc(満足していて、主要なsig))
Reagle Informational [Page 2] RFC 2807 XML Signature Requirements July 2000
[2ページ]RFC2807XML署名要件2000年7月の情報のReagle
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]
サイン-doc(満足していて、主要な署名): 署名は内容とキーの上の満足している保全/正当性、そして/または、主要な非repudiability4をもたらす強い一方向変換の値です。 作業部会は未来か「再-特許」の活動におけるそのような仕事に関する実現の可能性に関して報告するかもしれませんが、仕様は秘密性のメソッドを指定してはいけません。 [(Bugbee]5を記載してください。 仕様は暗号の署名の正当性をチェックするのに不可欠の主要な情報の支給を必要とするだけでよいです。 例えば、アイデンティティとキーリカバリー情報は特定用途に興味があるかもしれませんが、この仕様に基づき定義された必須情報のクラスの中にそれらはありません。 [(Reagle]6を記載してください。 仕様は、署名構文(すなわち、顕現と署名欄)をcanonicalizingして、論じ尽くす少なくとも1つのメソッドに定義しなければならないか、または参照をつけなければなりません。 [オスロ] 仕様は資源含有量[憲章]をcanonicalizingするメソッドを指定してはいけません、そのようなメソッドの上でセキュリティ要件を指定するかもしれませんが。 [オスロ] そのような内容は、適切な満足しているC14N(canonicalization)アルゴリズム[DOMHASH、XML-C14N]を指定することによって、正常にされます。 アプリケーションは、データを手渡す前に、アプリケーションの特定の意味論をXML Signatureアプリケーションに正常にするか、または署名の中でこのプロセスに必要な変換を指定すると予想されます。 [憲章。]7 XML Signatureアプリケーションは仕様が以下の通りでのconformantであるに違いありません: 1. それ自身の署名構文の中のXML-名前空間[XML-名前空間]。 アプリケーションはXML内容の中で名前空間をするか、または処理しないC14Nアルゴリズムを選ぶかもしれません。 例えば、いくつかのC14Nアルゴリズムがすべての名前空間宣言を取り除くために選ばれるかもしれなくて、他のものはあらゆる要素の中に文脈の独立している宣言に備える名前空間宣言を書き直すかもしれません。 2. それ自身の署名構文の中のXLink[Xlink]。 簡単なURI(断片IDのない)かfragmentIDsを超えたどんなリソース識別のためにも、アプリケーションはリソースであると署名される参照にXLinkロケータを使用しなければなりません。 署名アプリケーションは、署名している内容におけるXLink参照を埋め込むか、または広くしてはいけません、アプリケーションがこの特徴を提供するC14Nアルゴリズムを選ぶかもしれませんが。 3. それ自身の署名構文の中のXML-指針[XPointer]。 XMLドキュメントのアプリケーション参照/選んだ部分であるなら、それらはXLinkロケータの中でXML-指針を使用しなければなりません。 [WGがこれらの依存の操作を抑制するセキュリティ要件を指定するかもしれないWSリスト(1)]は一貫して安全な署名世代と操作を確実にします。 [オスロ]
Reagle Informational [Page 3] RFC 2807 XML Signature Requirements July 2000
[3ページ]RFC2807XML署名要件2000年7月の情報のReagle
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. 分散、URI、ウェブデータ、モジュール方式/レイヤリング/伸展性、および声明に関する声明としての主張の、より広いウェブ設計理念の一部としてXML Signaturesを開発しなければなりません。 [バーナーズ・リー、WebData] このような関係においては、既存の暗号のプロバイダー(そして、インフラストラクチャ)基関数は利用されるべきです。 [リスト(独奏)]
3. Requirements
3. 要件
3.1 Signature Data Model and Syntax
3.1の署名データモデルと構文
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 Signatureデータ構造は、リモート・データ・ファシリティデータモデル[リモート・データ・ファシリティ]に基づかなければなりませんが、リモート・データ・ファシリティ連載構文を使用する必要はありません。 [憲章。]2 XML Signaturesはロケータでアドレス可能などんなリソースにも適用します--非XML内容を含んでいます。 XML Signature指示物が顕現の中の外部の、または、内部のリソースを示すXMLロケータ(URIか断片)と同一視されている、(すなわち、アクセスしやすいネットワーク、同じXMLドキュメント/パッケージ、) [XFDL、バーナーズ・リー、ブラウンは(ヴィンセント)、Wを記載します] 3。 XML SignaturesはXMLドキュメントの部分か全体に適用できなければなりません。 [憲章、ブラウン]はコメントします: 考慮している関連する要件は、それらの部分1の除外で1つが署名する書類のそれらの一部が署名したがっていないのを示す能力をサポートするために仕様を必要としています。 この特徴で、1つはドキュメント閉鎖Listを持っている署名を作成できます。先祖情報を保有してください、そして、署名しなければならない非連続した領域の要素注文を保有してください。(ボワイエ(1)、私たちは(1)を通したこの要件が特別な<であると実装するのが、dsigであると考えています:、>要素を除いてください、(2)、(3) リソースロケータに伴うリスト、XML-断片またはXPointer仕様を除いてください; または、それらの仕様への要求された変化は機能性であるなら利用可能ではありません。この問題のさらなる議論に関してList(ボワイエ(1、2))を見てください。4 様々なキー、内容変換、およびアルゴリズム仕様(署名、ハッシュ、canonicalizationなど)を考えて、複数のXML Signaturesが静電気の上にウェブリソースで満足していた状態で存在できなければなりません; ブラウン5XML Signaturesは一流オブジェクト自体であり、参照をつけられて、その結果、署名することができなければなりません。憲章、バーナーズ・リー6仕様は様々なデジタル署名とメッセージ確認コードの使用を可能にしなければなりません、左右対称の、そして、非対称のauthなどのように材料[ブラウン]リソースかアルゴリズム識別子を合わせるダイナミックな協定と同様にentication体系は一流が反対して、URIでアドレス可能であるに違いないということです。[バーナーズ・リー]7XML Signaturesが含まれているかコード化されたリソースのオリジナルバージョンに適用できなければなりません。[WS-リスト(ブラウン/ハイムズ)]
Reagle Informational [Page 4] RFC 2807 XML Signature Requirements July 2000
[4ページ]RFC2807XML署名要件2000年7月の情報のReagle
3.2 Format
3.2 形式
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 SignatureはXML要素であるに違いありません。(XML1.0仕様の生産39で定義されるように。 [XML]) 2. (2) XML署名がドキュメントの中に置かれるとき、操作は根として(1) ドキュメントの根の要素タグを保存しなければなりません、そして、場所の署名要素の追加以外の根のdescendancy木はドキュメントの満足しているモデルで可能にしました。 例えば、署名されると、それの後のアプリケーションへのXML書類が署名されたとき、XMLフォームはまだ認識可能であるべきです。 [WS-概要] 3。 XML Signatureはconsituentの部品の署名の特性(保全、認証、および非repudiability)を保存している間に追加か削除による合成ドキュメントの生産を容易にするメカニズムを提供しなければなりません。 [憲章、ブラウンは(Bugbee]4を記載します。 XML Signaturesの重要な使用は離れているウェブ署名になるでしょう。 しかしながら、署名は、XMLかコード化された内容を中で埋め込まれているか、またはカプセル化するかもしれません。 [チャーターします] どんなW3C Recommendationも利用可能でないなら、このWGはパッケージとカプセル化の簡単なメソッドを指定しなければなりません。
3.3 Cryptography and Processing
3.3 暗号と処理
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つの署名がcanonicalization、内容canonicalizationであると実装するために義務的なハッシュ、および署名アルゴリズムを指定しなければなりません。 3. XML Signature構文と関連暗号の一滴の中の余分な属性の場合、XML SignatureアプリケーションはXML Signature意味論を好みます。 コメント: 別の可能性はしかしながら、誤りが生成されるべきであり、それが闘争が不注意に様々な機能とアプリケーション層の間に旗を揚げられるところでないということです。 4. 署名デザインと仕様テキストは、implementersが誤って共通の安全保障弱点(ダウングレードやアルゴリズム代替攻撃などの)に影響されやすい弱い実装を築き上げることを許可してはいけません。
3.4 Coordination
3.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 Signature仕様は以下のアプリケーションに関する必要条件を満たすべきです: 1. インターネットオープンTradingプロトコルv1.0[IOTP。]2 財政的なServicesマークUp Language v2.0[憲章。]3 少なくとも1つはアプリケーションを形成します。[XFA、XFDL]
Reagle Informational [Page 5] RFC 2807 XML Signature Requirements July 2000
[5ページ]RFC2807XML署名要件2000年7月の情報のReagle
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 Signature仕様を再検討しなければなりません: 1. XML構文作業部会: canonicalizationの依存。 [憲章。]2 XMLのリンクしている作業部会: 署名指示物。 [憲章。]3 XML図式作業部会: 署名図式デザイン。 [憲章。]4 メタデータコーディネートグループ: データはデザインをモデル化します。 [憲章。]5 W3C国際化営利団体: [交流レビュー] 6。 XMLは作業部会をパッケージします: パッケージの上の/の内容であると署名されます。 7. XMLは作業部会を断片化します: XML内容の部分に署名します。 コメント: WGのメンバーはXML断片とパッケージされたコンポーネントに署名して、処理するのに非常に関心があります。 ボワイエは、[XML-断片]が「保存されていた状態で接続コンポーネントの相対的な位置があるそのような方法によるドキュメントの非隣接の部分を特定しない」と断言します。 パッケージはXML Signatureアプリケーションに重要な能力ですが、それは明確に明確な信頼/意味の定義、パッケージアプリケーション要件、およびキャッシュのようなアプリケーション要件にさえ依存しています。 この仕事がどのように扱われるかは、明確ではありません。
4. Security Considerations
4. セキュリティ問題
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 Digital Signature要件をリストアップします。 その文脈では、このドキュメントの多くがセキュリティに関するものです。
5. References
5. 参照
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
交流レビューミーシャオオカミ。 「憲章は'Other Groupsとのコーディネート'でのセクションにI18N WGを含むべきである」 http://lists.w3.org/Archives/Team/xml- dsig-レビュー/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
ウェブアーキテクチャのバーナーズ・リーAxioms: URI5万フィートの http://www.w3.org/DesignIssues/Architecture.html からの http://www.w3.org/DesignIssues/Axioms.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- 署名-990618.htmlのためのデジタルSignatures
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
Reagle Informational [Page 6] RFC 2807 XML Signature Requirements July 2000
[6ページ]RFC2807XML署名要件2000年7月の情報のReagle
DOMHASH Maruyama, H., Tamura, K. and N. Uramoto, "Digest
Values for DOM (DOMHASH)", RFC 2803, April 2000.
DOMHASH丸山とH.と田村とK.とN.浦本、「ドム(DOMHASH)のためのダイジェスト値」、RFC2803、2000年4月。
FSML FSML 1.5 Reference Specification
http://www.echeck.org/library/ref/fsml-v1500a.pdf
FSML FSML1.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- 19990218.html
IOTP Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, April 2000.
IOTPバーデット、D.、「インターネットの開いている取り引きプロトコル--、IOTP、バージョン1インチ、RFC2801、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、「v1.0インターネットオープンTradingプロトコル(IOTP)のためのデジタルSignatures」、RFC2802、2000年4月。
Oslo Minutes of the XML Signature WG Sessions at IETF
face-to-face meeting in Oslo.
オスロでのIETFさしの会談におけるXML Signature WGセッションズのオスロMinutes。
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
リモート・データ・ファシリティリモート・データ・ファシリティの図式 http://www.w3.org/TR/1999/PR-rdf-schema-19990303 リモート・データ・ファシリティモデルと構文 http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Signature WG List http://lists.w3.org/Archives/Public/w3c-ietf-
xmldsig/
署名WG List 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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、8月1998日の 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
言語 http://www.w3.org/1999/07/WD-xlink-19990726 をリンクするXLink XML
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
Reagle Informational [Page 7] RFC 2807 XML Signature Requirements July 2000
[7ページ]RFC2807XML署名要件2000年7月の情報のReagle
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- 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 http://www.w3.org/TR/1999/REC-xml-names-19990114 のXML-名前空間名前空間
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ウェブアーキテクチャ: データ http://www.w3.org/1999/04/WebData を説明して、交換します。
6. Acknowledgements
6. 承認
This document was produced as a collaborative work item of the XML Signature (xmldsig) Working Group.
このドキュメントはXML Signature(xmldsig)作業部会の共同作業項目として製作されました。
7. Author's Address
7. 作者のアドレス
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 Jr.、W3C XML署名共同Chiarマサチューセッツ工科大学コンピュータ科学研究所W3C、NE43-350 545の技術の正方形のケンブリッジ、MA 02139
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
Reagle Informational [Page 8] RFC 2807 XML Signature Requirements July 2000
[8ページ]RFC2807XML署名要件2000年7月の情報のReagle
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
Copyright(c)2000インターネット協会とW3C(MIT、INRIA、慶応)、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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Reagle Informational [Page 9]
Reagle情報です。[9ページ]
一覧
スポンサーリンク
