English

XML署名要件
(XML Signature Requirements)

このメモの位置づけ

このメモは、インターネットコミュニティに情報提供するものです。 これは、いかなるインターネットスタンダードをも定めるものではありません。 このメモの配布に制限はありません。

著作権表記

Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.

要旨

この文書は、XML デジタル署名仕様策定に必要なのための設計原則、 範囲、要件をリストアップします。 この中に要件が含まれているのは、それが署名シンタックス、 データモデル、フォーマット、暗号処理、および、 外部に対する要求や外部との協調作業に関係してくるからです。

目次

• 1. はじめに
• 2. 設計原則と範囲
• 3. 要件
  • 3.1. 署名データモデルとシンタックス
  • 3.2. フォーマット
  • 3.3. 暗号と処理
  • 3.4. コーディネーション
• 4. セキュリティについての考慮事項
• 5. 参考文献
• 6. 謝辞
• 7. 著者のアドレス
• 8. 著作権表記全文

1. はじめに English

XML 1.0勧告 [XML] は、 XMLドキュメントと呼ばれるデータ オブジェクトのクラスのシンタックスを記述しています。 このワーキンググループの使命は、 デジタルコンテンツに対してなされる署名を表現するためのXMLシンタックスと、 そのような署名を処理し検証する手続きを開発することです。 署名は、データインテグリティの保証、本人認証、かつ／または、 否認防止といった機能を提供します。

この文書は、下記の3つの事項について、設計原則、範囲、 要件をリストアップします。： (1) WGの対象となる作業の範囲、(2) XML署名仕様、 (3) 仕様を実装するアプリケーション。 この中に要件が含まれているのは、それが署名シンタックス、 データモデル、フォーマット、暗号処理、および、 外部に対する要求や外部との協調作業に関係してくるからです。 ドキュメント中で、仕様に従うことが要求される事項は、 「なければならない(must)」として設計され、 オプショナルな任意である事項は「してもよい(may)」、 任意ではあっても推奨される事項は「必要がある(should)」と、 それぞれ表記されます。

2. 設計原則と範囲 English

1. 仕様には、デジタルコンテンツ、 特にXMLコンテンツに対してどのように署名するかが記載されなければなりません(must)。 (あらゆるコンテンツに対する)署名を表現するに使用されるXMLシンタックスは、 XML署名として記述されます。 [Charter]
2. XML署名は、正規形として表現された署名マニフェストのから計算された、 ハッシュ値を元にして生成されます。 (この文書中において、 マニフェストという用語は署名されるべきオブジェクトへの参照の集合体の意味で使用されます。 この定義に沿ったものでありさえすれば、 仕様は「マニフェスト(manifest)」でも、 この文書とは異なる「パッケージ」、 もしくはそれ以外の用語を用いてもかまいません(may)。 マニフェストは、Webリソースへの参照、 リソース・コンテンツのハッシュ、 (オプションとして)リソースコンテント種別をサポートしなければなりません(must)。 [Brown, List (Solo)] Webリソースは、 XLinkロケーター [XLink] のシンタックスを使用してアドレス付けすることのできる、 あらゆるデジタルコンテンツとして定義されます。
3. 署名の意味あいは単純です。： XML署名シンタックスは、ひとつの鍵を使って、 強力な一方方向の変換(transformation)によって、 マニフェスト中のリストされたリソースのコンテンツを関連づけます。
   1. XML署名シンタックスは、 任意のアプリケーション／トラスト・セマンティックスや、 assertion(断定)能力をサポート可能 -- 署名可能なように、 拡張可能でなければなりません(must)。 [Charter (Requirement1&4), List (Bugbee, Solo)]
   2. このWGの任務は、 トラスト・セマンティックスを定めることではなく、 通信の正当性 - valdity (認証性、インテグリティ、 否認拒否)の確保に不可欠なシンタックスとプロセッシングルールを定めることです。 [Charter (Requirement1)]
      議長の裁量により、またシンタックスの拡張性をテストするために、 本ワーキンググループにおいては、スキーマ定義[XML, RDF]もしくはリンクタイプ定義 [XLink] の中のWebリソースのsigned assertionsに関する共通のセマンティックス(例えば、 manifest - 表明, パッケージ, タイムスタンプ, endorsement - 保証, 等)を規定するnon-critical-path提案を作成するかもしれません。
      コメント：
      署名されたリソース(signed resource)の、 より形式的定義は以下の通りです。 この表記法では"定義(入力):制約"のように記述され、 定義は与えられた入力と制約の下で真(true)として評価されます。
      signed-resource(URI-of-resource, content, key, ):
      (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, 署名):
      署名とは、 コンテント及び鍵に対する強力な一方向性変換の値であり、 コンテントのインテグリティ/ヴァリディティ、および/あるいは、 鍵の否認防止性を与えます。
4. この仕様は、機密性保持手法を規定するものではありませんが、 ワーキンググループは将来、 もしくは別に設立された活動によりその実現可能性について報告するかもしれません。 [List (Bugbee)]
5. この仕様は、 暗号技術による署名の有効性をチェックするために必須の鍵となるような情報の提供のみを必要としています。 例えば、同一性や鍵回復(key recovery)の情報は特定のアプリケーションにとってだけ関心のあるものかもしれませんが、 これらはこの仕様により定義されるべき必須の情報クラスには含まれません。 [List(Reagle)]
6. この仕様は、 署名シンタックスの正規化及びハッシングに関する最低1つの手法を定義もしくはそれに対するリファレンスを与えます(つまりマニフェストと署名ブロック) [Oslo] 。 この仕様は、リソースコンテントの正規化手法は規定しません [Charter] が、 それらの手法についてのセキュリティ要件は規定するかもしれません [Oslo]。 このようなコンテントは、 適切なコンテント正規化(C14N)アルゴリズムを指定することで正規化(normalize)されます [DOMHASH, XML-C14N]。 アプリケーションには、 XML署名アプリケーションのデータハンドリングに優先するアプリケーション固有のセマンティックスの正規化もしくは、 署名に含まれるこのプロセスに必要な変換の特定が求められています [Charter]。
7. XML署名アプリケーションは、 下記のような仕様について準拠しなければなりません。：
   1. XML-namespaces [XML-namespaces]。 ただし、それ自身の署名シンタックスの範囲に限ります。 アプリケーションは、 XMLコンテンツの名前空間(namespace)を処理する、 もしくは処理しない正規化C14Nアルゴリズムを選択してもよいです(may)。 たとえば、 正規化アルゴリズムの中には全ての名前空間宣言を削除することを選ぶものもありますし、 全てのエレメントの中で文脈独立な宣言を与えるために名前空間宣言を書き換えるものもあります。
   2. XLink [Xlink]、 ただしそれ自身の署名シンタックスの範囲に限ります。 単純なURI(フラグメントIDを除く)もしくはフラグメントIDの及ばない、 任意のリソース同定(identification)のために、 アプリケーションは、 署名されたリソースを参照するのにXLinkロケーターを使用しなければなりません。 署名アプリケーションは、 署名されたコンテンツの中でXLink参照を埋め込んだり拡張してはなりません(must not)。 しかしアプリケーションはこの機能を提供する正規化アルゴリズムを選択しても良いです(may)。
   3. XML-Pointers [XPointer]、 ただしそれ自身の署名シンタックスの範囲に限ります。 もし、アプリケーションがXML文書の一部を参照/選択する場合、 アプリケーションはXLinkロケータの中でXML-Pointerを使用しなければなりません(must)。[WS-list (1)]
   このワーキンググループは、 これらの一貫性とセキュアな署名生成と運用を保つための依存関係の運用(operation)を制約するようなセキュリティ要件を規定します [Oslo]。
8. XML署名は、より広範ななWeb設計方針、つまり分散化, URI, Webデータ, モジュール化(modularity)/レイヤー化(layering)/拡張性, ステートメントに対するステートメントとしてのアサーション(assertions)などの一部として開発されるなければなりません(must)。 [Berners-Lee, WebData] この文脈の中で、 既存の暗号プロバイダー(およびインフラストラクチャ)プリミティブは利用されなけれりません。[List (Solo)]

3. 要件 English

3.1 署名データモデルとシンタックス English

1. XML署名データ構造は、 RDFデータモデル [RDF] に基づかなければなりません(must)が、 RDF一連番号シンタックスは用いる必要はありません(need not) [Charter]。
2. XML署名は、 ロケータによって指定される任意のリソース(非XMLコンテンツも含む)に対して適用されます。 外部もしくは内部を参照するmanifestの中で、 XML署名の対象(referents)はXMLロケータ(URIs or fragments)と同定(同一視)されます(つまり、 ネットワークアクセス可能であるか、 同一のXML文書/パッケージの中にあるということです)。 [Berners-Lee, Brown, List (Vincent), WS, XFDL]
3. XML署名は、 XML文書の部分もしくは全体に対して適用可能でなければなりません(must)。 [Charter, Brown]
   コメント：
   考慮の対象となっている関連する要件では、 署名することを望まない部分を除外して署名を行った文書の部分を示す能力のサポートの仕様化を求めています。 この機能は、元の情報を保持しながら、 またエレメントの署名されなければならない非連続領域の順序を保持しながら、 文書closure [List (Boyer(1))] を持った署名を行うことを認めます。 我々はこの以下のように要求の実装を考慮中です。
   (1) 特別なエレメント<dsig:exclude>,
   (2) リソースロケータを伴う除外リスト
   (3) XML フラグメントもしくは XPointer 仕様
   あるいは、 もしこの機能が実現できない場合、 それらの仕様の変更要求を行うことも考えられます。 この論点についてのさらなる検討については、 List(Boyer (1,2)) をご覧ください。
4. 多重(multiple) XML署名は、鍵、コンテンツ変換、 アルゴリズム仕様(署名、ハッシュ、正規化, etc.)が異なる状況の下で、 Webリソースの静的なコンテントの上で存在することができなければなりません(must)。 [Charter, Brown]
5. XML署名は、それ自身がファーストクラスオブジェクトであり、 その結果として、 署名自体が参照可能でかつ署名への署名も可能でなければなりません(must)。 [Berners-Lee]
6. この仕様は、対称・非対称認証スキームやdynamic agreement of keying materialなどの異なるデジタル署名とメッセージ認証コード(MAC)の使用を認めなければなりません(must) [Brown]。 リソースもしくはアルゴリズム識別子はファーストクラスオブジェクトであり、 URLにより指定されなければなりません(must) [Berners-Lee]。
7. XML署名は、 included/encodedリソースの元のバージョンに適用可能でなければなりません(must)。 [WS-list (Brown/Himes)]

3.2 フォーマット English

1. XML署名は、XMLエレメントでなければなりません(must)。 (XML1.0仕様 [XML] の39項に定義されている)
2. XML署名が文書中に置かれる場合、 この操作は(1) ルートとしての文書のルートエレメントタグ、 (2) 文書のコンテンツモデルによって認められた場所に置かれる署名エレメントの付加を除いたルートの下のツリー、 を保存しなければなりません(must)。 例えば、XMLフォームは署名されたとしても依然としてXMLフォームとしてそのアプリケーションに認識される必要があります(should)。 [WS-summary]
3. XML署名は、構成要素の署名の特性(インテグリティ, 本人認証, および否認防止)を保ちつつ、 (付加もしくは削除することで)複合ドキュメント生成能力を与えるメカニズムを提供しなければなりません(must)。 [Charter, Brown, List(Bugbee)]
4. XML署名の重要な使用法のひとつは、分離されたWeb署名となるでしょう。 しかし、署名はXMLもしくは符号化されたコンテンツの中にに含まれるもしくはカプセル化されて埋め込まれてもよいです(may)。 [Charter] 仮に適切なW3C勧告が無い場合、 本WGはパッケージングとカプセル化の単純な方法を定めなければなりません(must)。

3.3 暗号と処理 English

1. この仕様は任意の、暗号技術による署名方法、 メッセージ認証アルゴリズム、対称・非対称認証方法、 キーアグリーメント方法を認めなければなりません(must)。 [Brown]
2. この仕様は、署名正規化、コンテンツ正規化、ハッシュ、 署名アルゴリズムについて最低1つの必須の実装を定めなければなりません(must)。
3. XML署名シンタックスと関連する暗号モジュール(blobs)中の属性が冗長な場合、 XML署名アプリケーションは、 XML署名セマンティックスを優先します。 コメント：他の可能性としては、 各種の機能とアプリケーション層の間で発生するコンフリクトが起こる場所に無関係ではないが、 エラーが生成される必要があるとするものです。
4. この署名設計と仕様テキストは、 共通のセキュリティ上の弱点となりやすい弱い実装を間違って実装することを認めてはなりません(must not)。 (例えば、ダウングレード攻撃もしくはアルゴリズム置換攻撃(algorithm substitution attacks))。

3.4 コーディネーション English

1. XML署名仕様は、下記のアプリケーションの要件に適合する必要があります。：
   1. Internet Open Trading Protocol v1.0 [IOTP]
   2. Financial Services Mark Up Language v2.0 [Charter]
   3. 最低限1形態のアプリケーション [XFA, XFDL]
2. この文書中のすべての要件が適切に対応されるようにするため、 このXML署名仕様は、 下記のコミュニティのdesignatedメンバーによってレヴューされなければなりません。：
   1. XML Syntax Working Group: 正規化依存関係 [Charter]
   2. XML Linking Working Group: 署名リファラント(対象)[Charter]
   3. XML Schema Working Group: 署名スキーマ設計 [Charter]
   4. Metadata Coordination Group: データモデル設計 [Charter]
   5. W3C Internationalization Interest Group: [AC Review]
   6. XML Package Working Group: パッケージの中・全体への署名コンテンツ
   7. XML Fragment Working Group: XML部分コンテンツへの署名
   コメント：WGのメンバーは、 XMLフラグメントとパッケージコンポーネントへの署名と処理に大変関心があります。 Boyerは、[XML-fragment] は「接続されたコンポーネントの相対的なポジションが保護されるような方法で、 文書の隣接していない(non-contiguous)部分を特定する」ものではないと主張しています。 パッケージングはXML署名アプリケーションにとって決定的に重要なものです。 しかし、それは、明確なトラスト/セマンティック定義、 パッケージのアプリケーション要件、 さらにはcache-likeアプリケーション要件にすら明らかに依存しています。 この作業にどのように対応していくのかは明らかではありません。

4. セキュリティについての考慮事項 English

この文書は、署名シンタックス、データモデル、フォーマット、 暗号処理、外部要件とそれとのコーディネーションなどについて関連付けたようにXMLデジタル署名要件をリストしています。 この文脈で、この文書の大部分はセキュリティに関するものです。

5. 参考文献 English

6. 謝辞 English

この文書は、 XML署名(xmldsig)ワーキング・グループの共同作業アイテムとして作成された。

7. 著者のアドレス English

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

電話： 1.617.258.7621
EMail： reagle@w3.org
URL： http://www.w3.org/People/Reagle

翻訳者のアドレス

村野 正泰
情報処理振興事業協会
セキュリティセンター

EMail： m-murano＠ipa.go.jp
宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail： miyakawa＠ipa.go.jp

8. 著作権表記全文

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.

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.