ウィジェット 1.0 デジタル署名

W3C勧告候補2008年6月25日

このバージョン

http://www.w3.org/TR/2009/CR-widgets-digsig-20090625/

最新のバージョン

http://www.w3.org/TR/widgets-digsig/

以前のバージョン

http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/

http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/

http://www.w3.org/TR/2008/WD-widgets-digsig-20080414/

編集中の草案

http://dev.w3.org/2006/waf/widgets-digsig/

バージョン履歴

Twitterメッセージ（非編集上の変更のみ） ： http://twitter.com/widgetspecs （ RSS ）

編者

Frederick Hirsch、Nokia

Marcos Caceres、Opera Software ASA

Mark Priestley、Vodafone

著作権© 2009 W3C^®（マサチューセッツ工科大学、欧州情報科学数学研究コンソーシアム、慶應義塾大学）により、全ての権利が留保される。W3Cの免責、商標、文書利用規定が適用される。

概要

この文書では、ウィジェットパッケージ（widget package）にデジタル署名できるようにするために、XM署名 構文と処理 1.1仕様のプロファイルを定義するものである。ウィジェットの作成者（author）と配布者（distributor）は、作成および配布の継続性を確保するための機構として、ウィジェットにデジタル署名することができる。インスタンス化に先立ち、ユーザーエージェントはウィジェットパッケージの完全性を検証するためや、署名鍵を確認するために、デジタル署名を用いることができる。この仕様書では、ウィジェットパッケージとユーザーエージェント間の適合性要件を規定する。

この文書の位置づけ

この仕様書は、ウィジェット1.0：デジタル署名仕様の2009年6月25日勧告候補版である。W3Cは、この文書が開発者コミュニティでの実装を奨励し、安定させると思われる、ということを示すために勧告候補を発行している。ウェブアプリケーション（WebApps）作業部会では、ひとたび作業部会が包括的なウィジェット 1.0: デジタル署名テストスイートを開発すれば、ディレクターがこの文書を勧告案に進め、少なくとも2つの相互運用可能な実装で実証することを要求すると見込んでいる。ウェブアプリケーション作業部会では、2009年9月までにこれらの実装を見込んでいる。作業部会では、2009年10月1日より前に勧告案へ進めたいとは考えていない。現時点で、この仕様書の実装報告は挙がっていない。

勧告候補の発行は、W3C会員による承認を意味しない。これは策定中の仕様書であり、いつでも他の文書によって更新、交換、廃止されることがある。作業途中でない正式な仕様書としてこの仕様書を引用することは適当でない。

今節では、公開時点でのこの仕様書の位置づけについて説明する。他の文書が、この文書に優先するかもしれない。現在のW3Cの発行物の一覧とこの技術レポートの最新版は、W3Cの技術レポート目録http://www.w3.org/TR/で参照できる。

この仕様書は、2004年2月5日版のW3C特許ポリシの下で、部会の手によって作成された。W3Cでは部会の成果物に関連する特許開示の公開リストを維持しており、そのページには特許開示のための手順が含まれている。必要不可欠な請求項（Essential Claim(s)）があると思われる、特許の実際の知識を持っている個人は、W3C特許ポリシの第6節にしたがって情報を開示する必要がある。

閲覧者はW3CのCVSリポジトリにてこの仕様書の最新の編集者草案を参照することができ、それは頻繁にに更新されている。一般の方は、ウェブアプリケーション作業部会の公開メーリングリストpublic-webapps@w3.org（アーカイブ）にコメントを送信することを推奨する。W3Cのメーリングリストとアーカイブ利用ガイドラインを参照せよ。以前の版からの詳細な変更点の一覧は、W3CのCVSサーバから入手可能である。

始めに

この仕様書では、ウィジェットパッケージにデジタル署名できるように、XM署名 構文と処理 1.1仕様のプロファイルを定義するものである。ウィジェットの作成者（author）と配布者（distributor）が、作成と配布の継続性を保つための機構として、ウィジェットにデジタル署名することができる。インスタンス化に先立ち、ユーザーエージェントはウィジェットパッケージの完全性を検証するためや、署名鍵を確認するために、デジタル署名を用いることができる。この仕様書では、ウィジェットパッケージとユーザーエージェント間の適合性要件を規定する。

ウィジェットパッケージは、署名ファイル以外の全ファイルエントリを暗号化して内包するXML署名1.1形式の署名で、ウィジェット作成者本人によって署名される。ウィジェットパッケージは、作成者署名と同様に、全ての非署名ファイルエントリをそれぞれ暗号化して内包したXML署名1.1形式の署名が作成され、1つまたは複数のウィジェット配布者によって署名される。

バージョン、名前空間と識別子について

この仕様書では、リソース、アルゴリズム、セマンティクスの識別にXML名前空間と統一リソース識別子（URI）を用いる。

この仕様書の実装では、この仕様書で用いられるXML要素用のXML名前空間として下記URIを用いなければならない[MUST]。

URI:

http://www.w3.org/ns/widgets-digsig

実装は、XML仕様とXML名前空間仕様に対応しなければならない[MUST]。

上記の名前空間URIを用いるには、この仕様書で用いるXML要素が必要[REQUIRED]だが、下記の名前空間接頭辞と実体宣言は、この仕様書で用いる編集上の慣習に過ぎない。それらの利用については、デジタル署名文書の著者によって選択できる[OPTIONAL]。

XML内部実体:

<!ENTITY wsig "http://www.w3.org/ns/widgets-digsig">

名前空間接頭辞:

wsig:

この仕様書の制御下にないリソースについては、関連する仕様書によって定められたURIで指すものを用いる。たとえば、

XML署名 第2版のリソースは、ds:名前空間で定義されている。

http://www.w3.org/2000/09/xmldsig

追加のXML署名1.1のリソースは、ds11:名前空間で定義されている。

http://www.w3.org/2009/xmldsig11

Roleのような個々の署名のプロパティ群であるXML署名プロパティは、dsp:名前空間で定義されている。

http://www.w3.org/2009/xmldsig-properties

XMLセキュリティで用いられるアルゴリズムは、XML署名1.1の諸所で定義されている。

詳細についてはXMLセキュリティのクロスリファレンスを参照せよ。

註：この仕様書中では明確なバージョン番号は規定しない。この仕様書の将来版で文書形式の明確な版数が求められるならば、異なる名前空間が用いられるだろう。

定義について

ウィジェットパッケージとは、ウィジェットのパッケージング仕様に沿ったZipアーカイブである。

ファイルエントリとは、ローカルファイルヘッダ、ファイルデータ、（追加の）データディスクリプタによって保持されたデータであり、Zip仕様で定義されたように、それぞれの物理的なファイルはZipアーカイブの中に格納されている。

ウィジェットパッケージのルートとは、ウィジェットのパッケージング仕様で定義された、一つ、あるいは複数のファイルエントリを論理的に含むことが可能な、ウィジェットパッケージの最上位レベルパスである。

ファイル名とは、ウィジェットのパッケージング仕様で定義された、ウィジェットパッケージに含まれる（ファイルエントリのローカルファイルヘッダのファイル名フィールドから導き出された）ファイルの名前である。すべてのファイル名は、文字の大小を区別（case-sensitive）されなければならない[MUST]。いわゆる、ファイル名比較時の懸案事項である。

デジタル署名済みのウィジェットパッケージとは、一つあるいは複数の署名ファイルを含んだウィジェットパッケージである。

未署名のウィジェットパッケージとは、任意の署名ファイルを含まないウィジェットパッケージである。

署名ファイルとは、署名ファイル名の命名規則に従った名前の、（この仕様書で説明しているような）分離した（detached）XML署名1.1形式の署名を含んだファイルエントリである。

署名ファイル名とは、署名ファイルを表すファイルエントリのファイル名である。この仕様書では、作成者署名と配布者署名の両方について命名規則を定義している。

ウィジット署名とは、XML署名1.1形式の署名であり、署名ファイルに内包されている。

作成者署名とは、作成者署名の命名規則を遵守していて、URI属性がauthor role属性値と等しいXML署名プロパティのRole要素を持った、署名ファイル名付きのウィジェット署名である。作成者署名は、ウィジェットの作者（つまり、ウィジェットを作成したその人）によって生成されることを意図している。

配布者署名とは、配布者署名の命名規則を遵守していて、URIがdistributor role属性値と等しいXML署名プロパティのRole要素を持った、署名ファイル名付きのウィジェット署名である。配布者署名は、ウィジェットの配布者（つまり、作成者に代わってウィジェットの配布を行っている第三者）によって生成されることを意図している。

ウォールクロックタイムスタンプ（wall clock timestamp）は、XML署名プロパティ仕様で定義されている。

Zip相対パスは、ウィジェットのパッケージング仕様で規定されているように、zip-rel-path用のABNFに従わなければならない[MUST]。

規約について

今節は参考情報である。

定義済みの用語は、定義済み用語の見本というように現れる。そのような用語は、定義済み用語の見本というふうに参照され、用語が定義された場所に戻るリンクを提供する。

適合性条項あるいは検証可能な主張を意味する言葉として、RFC 2119にある「しなければならない[MUST]」、「してはならない[MUST NOT]」、「求められる[REQUIRED]」、「すべきである[SHOULD]」、「すべきでない[SHOULD NOT]」、「推奨される[RECOMMENDED]」、「してもよい[MAY]」、「選択できる[OPTIONAL]」という用語を用いる。

変数は、例えば変数というふうに特別にフォーマットされる。コードも同じく、コードというふうに特別にフォーマットされる。

事例部分は、以下のように全体を示すためにハイライト表示される。

これは、あるコードを含んだ例である。
if (a <> 1234122){ //...do something }

注記は特別にハイライト表示され、編集上の問題やよく知られた事柄を注記するために用いられる。

この仕様書では、ファイル名を定義するためにABNF構文を用いる。ルールは、互いに隣り合って記載されたものと連結されている。ルールでは、ゼロ以上を意味する*を冠している。この構文の詳細については、ABNFを参照せよ。

事例について

今節は参考情報である。

signature1.xmlと名づけられた配布者署名文書の例である。

<?xml version="1.0" encoding="UTF-8"?>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" 
   Id="DistributorASignature">
  <SignedInfo>
   <CanonicalizationMethod 
    Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
   <SignatureMethod
    Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
   <Reference URI="config.xml">
    <DigestMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <DigestValue>...</DigestValue>
   </Reference>
   <Reference URI="index.html">
     <DigestMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue>...</DigestValue>
   </Reference>
   <Reference URI="icon.png">
    <DigestMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <DigestValue>...</DigestValue>
   </Reference>
   <Reference URI="#prop">
    <DigestMethod 
     Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <DigestValue>...</DigestValue>
   </Reference>
  </SignedInfo>
  <Object Id="prop"> 
   <SignatureProperties
    xmlns:dsp="http://www.w3.org/2009/xmldsig-properties">
    <SignatureProperty Id="profile" Target="#DistributorASignature">
     <dsp:Profile URI="http://www.w3.org/ns/widgets-digsig#profile"/>
    </SignatureProperty> 
    <SignatureProperty Id="role" Target="#DistributorASignature">
     <dsp:Role
       URI="http://www.w3.org/ns/widgets-digsig#role-distributor"/>
    </SignatureProperty> 
    <SignatureProperty Id="identifier" Target="#DistributorASignature">
     <dsp:Identifier>07425f59c544b9cebff04ab367e8854a</dsp:Identifier>
    </SignatureProperty> 
   </SignatureProperties> 
  </Object>  
  <SignatureValue>...</SignatureValue>
  <KeyInfo>
   <X509Data>
    <X509Certificate>...</X509Certificate>
   </X509Data>
  </KeyInfo>
 </Signature>

設計の目標と要件について

この仕様書の設計目標と要件は、ウィジェット 1.0 要求仕様で取り組まれている。この仕様書では、下記の要求事項に取り組む。すなわち、

• R48. デジタル署名：この仕様書がこの要求事項に取り組むために、XML署名1.1とRFC 5280が欠かせない。
• R49. 複数の署名と証明書チェーン：この仕様書がこの要求事項に取り組むために、XML署名1.1とRFC 5280が欠かせない。
• R50. 署名文書形式：署名ファイルを参照せよ。
• R51. 複数のメッセージダイジェストアルゴリズムへの対応：この仕様書では、reference要素、ds:SignedInfo要素でSHA-256に対応する。
• R52. 複数の署名アルゴリズムへの対応：DSA-SHA-1、RSA-SHA-256、ECDSA-SHA-256
• R53. 鍵長：最小で1024ビットだが、2048ビットを推奨。
• R54. 拡張鍵用途情報（Key Usage Extension）：X.509v3の一部。
• R55. 失効情報の取り込み：この仕様書がこの要求事項に取り組むために、XML署名1.1とRFC 5280が欠かせない。

特に、この仕様書では作成者署名と配布者署名の両方に明示的に対応する。

適合性について

この仕様書内の、しなくてはならない[MUST]、してはならない[MUST NOT]、求められる[REQUIRED]、すべきである[SHOULD]、すべきでない[SHOULD NOT]、推奨される[RECOMMENDED]、してもよい[MAY]、選択できる[OPTIONAL]というキーワードは、RFC 2119で記述されたように解釈される。

参考情報と記された節と同様に、この仕様書内の例、ノート、セキュリティ上の考慮事項は参考情報である。この仕様書内のその他の部分は規範的である。

この仕様書への適合性を表示可能なプロダクトの種類は、以下の二つである。

• 署名ファイル
• ユーザエージェント

ウィジェット署名を生成するプロダクトは、この仕様書とXML署名 1.1に適合するXML文書を生成しなくてはならない[MUST]。

ユーザーエージェントとは、この仕様書に対応しようとする実装である。ユーザーエージェントは、適合性表示をするためにこの仕様書によって記述されたように振舞わねばならない[MUST]。

実装者には、パッケージ内のデジタル署名の検証を可能とするために、エンドユーザに証明書をインストールできるようにするメカニズムを提供することが奨励される。

ウィジェット用デジタル署名の配置と処理について

今節では、処理のためにウィジェットパッケージ中の署名ファイルをどのように配置するかを定義する。実装では、ウィジェットパッケージ中に署名ファイルを配置するために、後述するアルゴリズムを用いて常に同じ結果を得なければならない[MUST]。

1. signaturesを空のリストにする。
2. ウィジェットパッケージのルートにある各ファイルエントリに対し、ファイル名が配布者署名の命名規則に合致するならば、signaturesリストへこのファイルエントリを追加する。実装では、文字の大小を比較しなければならない[MUST]。
3. signaturesリストが空でない場合、signaturesのリストをファイル名フィールドの数字を昇順で（例えば、signature1.xmlの次にsignature2.xml、その次にsignature3.xmlというように）ソートする。
4. ウィジェットパッケージのルートを検索し、作成者署名の命名規則に合致する任意のファイル名のファイルエントリをsignaturesに追加する。実装では、文字の大小を比較しなければならない[MUST]。
5. signaturesが空（署名ファイルを意味するものが見つからなかった）の場合、このアルゴリズムを中止し、未署名のウィジェットパッケージとしてこのウィジェットパッケージを扱う。

6. 先頭に配布者署名があるなら、署名リストの数字の降順に署名ファイルを検証する。

   どの配布者署名に決定するかは検証されることになるが、作成者署名が検証されるかどうかはこの仕様書の範囲外である。

   これは、ユーザエージェントが用いるセキュリティポリシによって決定してよい[MAY]。

   番号順とは、署名ファイル名の数字部分に基づいて並べることである。

   したがって、複数の配布者署名が処理されることになる場合、最も高い番号付けがされた配布者署名が最初に処理される。

   ファイル名の数字部分でウィジェット署名ファイルを並べることで、一貫した処理を可能にし、最適化が可能となる。

7. あらゆる検証対象の署名は、この仕様書で定義された署名検証方法（Signature Verification）に従って検証されねばならない[MUST]。