ウィジェット 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]。

署名構文とウィジェットパッケージでの利用について

ウィジェットでのXML署名の利用について

ウィジェットパッケージは、この仕様書で定義されるXML署名 1.1のプロファイルを用いてデジタル署名してもよい[MAY]。

註記：ユーザエージェントのセキュリティポリシは、署名の検証が操作にどう影響するかに作用するかもしれず、CRLs（RFC 5280）やOCSP（RFC 2560）を用いた証明書失効処理と証明書チェインの検証に追加要件を含んだ、信用確立上の追加制約があるかもしれない。

セキュリティポリシでは、ds:KeyInfoで伝えられる追加情報も必要とする可能性がある。セキュリティポリシについてはこの仕様書の範囲外だが、署名ファイルを処理するのための重要な意味を持つ。

この仕様書に従ってウィジェットパッケージを署名するとき、以下のウィジェット署名での要求事項がウィジェットパッケージ中に含まれる全てのウィジェット署名へ適用される。

• それぞれの署名ファイルは、ウィジェットパッケージのルートに現れなければならない[MUST]。
• それぞれのウィジェット署名は、XML署名 1.1構文に準拠した分離（detached）XML署名でなければならない[MUST]。
• それぞれのウィジェット署名は、XML署名 1.1処理方法のルールに準拠して生成と検証がなされねばならない[MUST]。
• それぞれのウィジェット署名は、この仕様書とXML署名プロパティに準拠したdsp:Profile署名プロパティを含まねばならない[MUST]。このdsp:Profileプロパティは、URI属性値がhttp://www.w3.org/ns/widgets-digsig#profileでなければならない[MUST]。
• それぞれのウィジェット署名は、この仕様書とXML署名プロパティに準拠したdsp:Role署名プロパティを含まねばならない[MUST]。
• それぞれのウィジェット署名は、この仕様書とXML署名プロパティに準拠したdsp:Identifier署名プロパティを含まねばならない[MUST]。
• ウィジェット署名で用いられるすべてのds:Referenceは、URI属性を持たねばならない[MUST]。
• ウィジェット署名で用いられるすべてのds:Referenceは、後述する2種類の参照方法のどちらか一つでなければならない[MUST]。

  同一のds:Signature要素内容への参照

  ウィジェット署名項目へのすべてのds:Referenceは、ds:ReferenceのURI属性にIDREF値を用いねばならず[MUST]、ウィジェット署名中で（XMLスキーマのデータ型で定義されたような）一意の識別子を参照する。

  同一ウィジェットパッケージ中のファイルエントリへの参照

  ファイルエントリへ対するすべてのds:ReferenceのURI属性は、ウィジェットパッケージの内部ファイルを識別するzip相対パスをURLエンコードしたものでなければならない[MUST]。

作成者署名について

作成者署名とは、次のものを決定付けるために用いられる。

• ウィジェットの制作者を決定する。
• ウィジェットの完全性が作成者の意図するものであることを決定する。
• 2つのウィジェットが同一の作者のものであるかどうかを決定する。

ウィジェットパッケージは、ゼロあるいは一つの作成者署名を含んでもよい[MAY]。

ウィジェット署名での要求事項に加えて、以下のものが作成者署名にあるXML署名プロパティのRole要素中のURI属性値にあてはめられねばならない[MUST]。すなわち、

作成者のRole属性値（URI）:

http://www.w3.org/ns/widgets-digsig#role-author

意味

このウィジェット署名が、ウィジェットパッケージの作成者のデジタル署名を表す。

加えて、ds:Signatureは、任意のウィジェット署名以外の、ウィジェットパッケージの全ファイルエントリへのds:Referencesを持たねばならない[MUST]。

作成者署名の命名規則について

ABNFのauthor-sig-filenameルールでは作成者署名の命名規則を定義しており、それを作成者署名の署名ファイル名として適用する。すなわち、

author-sig-filename = %x61.75.74.68.6f.72.2d.73.69.67.6e.61.74.75.72.65.2e.78.6d.6c

author-sig-filenameルールでは、小文字の（文字の大小を区別した）文字列「autuor-signature.xml」を定義している。

ABNFのauthor-sig-filenameルールでのファイル一致作業では、この仕様書で定められた作成者の役割のためのURIをもったdsp:Role署名プロパティを含まねばならず[MUST]、さもなくば署名はエラーとして判定されねばならない[MUST]。

配布者署名について

配信者署名とは、次のものを決定付けるために用いられる。

• 特別な配布者によって、このウィジェットリソースが配布されていることを決定する。
• ウィジェットパッケージの完全性が、配布者の意図するところであることを決定する。

ウィジェットパッケージには、ゼロ、一つ、複数の 配信者署名が含まれてよい[MAY]。

ウィジェット署名での要求事項に加えて、以下のものが配信者署名のXML署名プロパティのRole要素のURI属性値にあてはめられねばならない[MUST]。すなわち、

配布者のRole属性値（URI）:

http://www.w3.org/ns/widgets-digsig#role-distributor

意味

このウィジェット署名が、ウィジェットパッケージの配布者のデジタル署名を表す。

加えて、ds:Signatureには、ウィジェットパッケージの全ファイルエントリへのds:Referencesを含まねばならない[MUST]ず、任意の作成者署名を含む。しかし、任意の配布者署名は除く。言い換えると、 配布者署名は作成者署名へ連署（countersign）しなければならない[MUST]が、他の配布者署名へ連署してはならない[MUST NOT]。

配布者署名の命名規則について

それぞれの配布者署名は、小文字の文字列で「signature」、その次に1～9の範囲の数字、その次にゼロ個あるいは複数の0～9の範囲の数字、最後に小文字の文字列で「.xml」というファイル名規則に従わねばならない[MUST]。

ABNFのdist-sig-filenameルールでは、配布者署名の命名規則が厳格に定義されており、それを配布者署名の署名ファイル名に適用する。

dist-sig-filename = signature-string non-zero-digit 
                            *DIGIT  xml-suffix-string
signature-string  = %x73.69.67.6e.61.74.75.72.65
non-zero-digit    = %x31-39
xml-suffix-string = %x2e.78.6d.6c

• signature-stringルールでは、小文字の（文字の大小を区別した）文字列で「signature」と定義している。
• non-zero-digitルールでは、1～9の範囲の数字を定義している。
• DIGITとは、ABNFにおいて0～9の範囲の数字として定義されている。
• xml-suffix-stringルールでは、小文字の（文字の大小を区別した）文字列で「.xml」と定義している。

一つ例を挙げると、「signature20.xml」である。

数字はゼロで始まること（Leading zeros）が許されない。

上記のABNFに一致しないファイル名のファイルエントリは無視されねばならず[MUST]、それは実装がそのファイルエントリを署名ファイルとして取り扱ってはならない[MUST NOT]ことを意味する。

たとえば、ファイル名が「signature01.xml」のファイルは無視される。

連続した数値をもった配布者署名の署名ファイル名は、選択できる[OPTIONAL]。

ウィジェットパッケージの中で、これらの署名ファイルは署名ファイル名の数字位置を元に並び替えられねばならない[MUST]。

その例を挙げると、 signature2.xmlはsignature11.xmlの前に来る。

ABNFのdist-sig-filenameルールのファイル一致作業では、この仕様書で定義された配布者の役割のためのURIを持ったdsp:Role署名プロパティを含まねばならなず[MUST]、さもなくば署名がエラーであるように判定されねばならない。

X.509データについて

すべてのウィジェット署名では、XML署名 1.1仕様で定義された、署名のds:X509Data要素に追加情報を持ってもよい[MAY]。これにはX.509証明書、CRL、OCSPレスポンス情報を含んでもよい[MAY]が、仮に含まれるならばXML署名 1.1仕様に準拠することで伝搬されねばならない[MUST]。

証明書においてds:X509Dataを用いるときは、X.509証明書フォーマットに対応しなければならない[MUST]。これは不可欠な証明書フォーマットである。推奨される[RECOMMENDED]証明書フォーマットのバージョンは、RFC 5280で定義されたX.509バージョン3である。実装では、RFC 5280のX.509 v3証明書を受け入れる用意ができていなければならない[MUST]。

註: v3証明書では、証明書での基本制約を表明するためにv3拡張を使用する必要がある。これによって、CA証明書をエンド主体（end entity）証明書と区別できるようになり、より強固な信頼の検証が可能になる。

Identifier署名プロパティについて

署名者は、署名管理を有効にして一意に署名を区別するためにdsp:Identifier署名プロパティを用いる。それは署名者固有のものでなければならない[MUST]。署名当事者は、dsp:Identifier署名プロパティが、署名するウィジェットパッケージに対して一意であることを確認するはずである。

アルゴリズムについて

この仕様書にXML署名 1.1との違いがあるとしても、XML署名 1.1で定義されたアルゴリズムのURI識別子定義が優先される。これらのアルゴリズムの利用についてXML署名 1.1で定められたルールは、後述するものとならねばならない[MUST]。必須でないアルゴリズムを用いることは、それらのアルゴリズムに対応しない実装で相互運用できない署名になる可能性があることに留意せよ。この検討によって作成者に注意を促すものである。

署名アルゴリズムについて

以下の署名アルゴリズムに対応しなければならない[MUST]。すなわち、

SHA-256を用いたRSA

http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

SHA-1を用いたDSA

http://www.w3.org/2000/09/xmldsig#dsa-sha1

署名検証のためには（対応が）必須とされ[REQUIRED]、作成のためには（対応を）選択できる[OPTIONAL]。

以下の署名アルゴリズムに対応すべきである[SHOULD]。すなわち、

SHA-256を用いたECDSA

http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256

これは、FIPS 186-3のD.2.3節で定義されたP-256曲線（とSHA-256ハッシュアルゴリズム）を用いたECDSAである。

註：全ての実装がこの追加アルゴリズムには対応しないかもしれないが、この仕様書のその後の発行時に必須となるかもしれないので、実装が推奨される。なんらかのセキュリティ問題が既存の必須アルゴリズムに発見されれば、これらも必須となるかもしれない。

ユーザエージェントは追加の署名アルゴリズムに対応してよい[MAY]。

署名を作成するために用いる鍵の推奨される[RECOMMENDED]鍵長（推奨鍵長）は、2048ビットである。署名を作成するために用いる鍵の鍵長は、1024ビットより短くあってはならない[MUST NOT]。署名者は、署名の有効期限が1年より短い場合を除き、2048ビットより短い鍵長を用いた署名を作成してはならない[MUST NOT]。

ダイジェストアルゴリズムについて

以下のダイジェストアルゴリズムに対応しなければならない[MUST]。すなわち、

必須[REQUIRED]：SHA-256

http://www.w3.org/2001/04/xmlenc#sha256

ユーザエージェントは追加のダイジェスト作成法に対応しても良い[MAY]。

正則化アルゴリズムについて

以下の正則化アルゴリズムに対応しなければならない[MUST]。すなわち、

必須[REQUIRED]：排他的XML正則化 1.0（注釈なし）

http://www.w3.org/2001/10/xml-exc-c14n#

ユーザエージェントは追加のXML正則化方法に対応しても良い[MAY]。

処理規則について

署名生成と検証のための共通制約について

後述する制約事項が、署名作成と署名検証の両方に課される。これらの制約事項は、ウィジェット署名を作成するときに遵守されねばならず[MUST]、同様にウィジェット署名を検証する際に照合することによって検証されねばならない[MUST]。

1. ウィジェット署名は、ウィジェット署名でない全ファイルエントリへのds:Referenceを持たねばならない[MUST]。
2. 配布者署名は、ウィジェット署名の中に作成者署名があるなら、全ての作成者署名へのds:Referenceを持たねばならない[MUST]。
3. ds:Reference要素毎に
   1. URI属性は、ウィジェットパッケージのルートから参照されているファイルエントリへのzip相対パスでなければならない[MUST]。
   2. dfs:digestMethodのAlgorithm属性は、ダイジェストアルゴリズムのうちの一つでなければならない。
   3. ds:Referenceは、任意のds:Transform要素を持ってはならない[MUST NOT]。
4. この仕様書で要求される全署名プロパティは、以下のように署名に組み込まれねばならない[MUST]。すなわち、
   1. ウィジェット署名は、ds:Signature要素の中にds:Object要素を含まねばならない[MUST]。このds:Object要素は、署名のds:SignatureInfo要素のなかにあるds:Reference要素によって参照された、Id属性を持たねばならない[MUST]。
   2. このds:Object要素は、この仕様書で要求されるプロパティごとに異なるds:SignatureProperty要素を必ず[MUST]含んだ、唯一つのds:SignatureProperties要素を含まねばならない[MUST]。
   3. この仕様書で要求される各ds:Signatureプロパティでは、XML署名プロパティの構文要件を満たさねばならない[MUST]。
5. ds:Signatureは、以下の要件を満たさねばならない[MUST]。すなわち、
   1. ds:CanonicalizationMethod要素のAlgorithm属性は、正則化アルゴリズムの一つでなければならない[MUST]。
   2. ds:SignatureValue要素で用いられるds:SignatureMethodアルゴリズムは、署名アルゴリズムの一つでなければならない[MUST]。ds:Signatureは、推奨される鍵長、あるいはそれ以上（すなわち2048ビットより長い）の鍵を用いて作成されねばならない[MUST]。
   3. ds:KeyInfo要素を含んでもよく[MAY]、ds:KeyInfo要素は、証明書、CRL、およびOCSP情報を含んでもよい。その場合は、XML署名 1.1仕様に準拠しなければならない[MUST]。証明書が使用されている場合、証明書は必須の証明書形式に従わねばならない[MUST]。
   4. ds:SignedInfo要素は、今節の1、2、4に挙げられたds:Reference要素を全て含まねばならない[MUST]。
6. ウィジェット署名はUTF-8で符号化されたXML文書としてデータ化（シリアライズ）されねばならず[MUST]、適切な命名規則、すなわち、配布者署名用の命名規則、あるいは作成者署名用の命名規則のいずれかに従って名前付けされねばならない[MUST]。

署名生成について

ウィジェット署名は、リファレンス生成（Reference Generation)と署名生成（Signature Generation）上の規則を含んだ、XML署名 1.1のコア生成規則（Core Generation rules）に従って作成されねばならない[MUST]。

署名生成と検証のための共通制約が、署名生成において満たされねばならない[MUST]。

署名のための一意な識別子文字列が、署名者によってdsp:Identifier署名プロパティに配置されねばならない[MUST]。この文字列は、署名者によって作成された全てのウィジェット署名にとって一意な署名文字列でなければならない[MUST]。署名当事者は、dsp:Idenfier署名プロパティ値が、署名するウィジェットにとって一意であるように期待する。

署名検証について

ウィジェット署名は、リファレンス検証（Reference Validation）と署名検証（Signature Validation）を含む、XML署名 1.1で定義されたコア検証（Core Validation）に従って検証されねばならない[MUST]。

署名作成と検証のための共通制約が、署名検証において満たされねばならない[MUST]。

ds:KeyInfo要素が存在するならば、その要素はXML署名 1.1仕様に準拠しなければならない[MUST]。ユーザエージェントは、署名鍵について[#rfc5280|[RFC 5280]]の基本パス検証（Basic Path Validation）を行わねばならず[MUST]、必要に応じて失効チェックを行うべきである[SHOULD]。

ウィジェット署名の検証が成功するなら、ウィジェット署名の検証に依存する任意の外部実体（例えば、ウィジェットパッケージング仕様を実装したユーザエージェント）は、成功の通知を受けねばならない[MUST]。

ウィジェット署名の検証が何らかの理由で失敗するなら、ウィジェット署名の検証に依存する任意の外部実体（例えば、ウィジェットパッケージング仕様を実装したユーザエージェント）は、失敗の通知を受けねばならない[MUST]。この仕様書では、失敗通知の形式や内容について定義せず、実装者に一任する。実装によって、検証失敗の理由が、任意の外部実体に対して返されてもよく[MAY]、それには基準検証、署名検証、署名プロパティ検証、および証明書、CRL/OCSP検証に関する理由が含まれる。

セキュリティに関する考慮事項

今節は参考情報である。

この仕様書で説明した署名方式は、圧縮されたウィジェットパッケージの内部に存在するコンテンツを扱っている。これは、ウィジェット署名を検証するために、未知のソースからやってくるデータストリームを展開（decompress）する必要がある、という意味である。この仕様書に従う署名では、攻撃対象となる署名の抽出（extraction）と検証の間に用いられる抽出（unpacking）と展開のコードを制限しない。

署名検証の間、悪意を持って作られたウィジェットパッケージによるリソース枯渇攻撃を避けるために注意すべきである。

ウィジェットパッケージで見つけたパスコンポーネントを信頼する場合に、実装は注意するべきである。そのようなパスコンポーネントは、オペレーティングシステムがセキュリティ上で重要なファイルと位置づけた正規のウィジェット環境の外にあるもの、として解釈されるかもしれず、不用意にファイルシステムへウィジェットパッケージを展開すると、スタートアップあるいはシステムファイルの上書きのような、セキュリティ上望ましくない効果を引き起こす可能性がある。

ウィジェットパッケージの全ファイルを取り込んだ単一の署名ファイルは存在しないが、全ての署名ファイルを取り込んだものは存在する。これにより、ウィジェットパッケージが配布者署名への攻撃（配布者署名の削除や追加）をうけることがなくなる。作成者署名もまた、作成者署名や任意の配布者署名が存在している場合に、それらを削除されることによって攻撃を受ける可能性がある。署名ファイルも名前を変更されるかもしれず、それによって配布者署名の処理順に影響を与えることができる。

新たなルート証明書をユーザエージェントにインストールする機構は、セキュリティ上で重要な機構である。エンドユーザは、新たなルート証明書をインストールする際にそれらがなぜ、何をしているのかに注意すべきである。