この文書は、W3Cノート SOAP Security Extensions: Digital Signatureの翻訳である。正式な版は、W3Cのサイトにある英語版であってこの翻訳ではない。この翻訳は原文と技術的に等価なことを意図しているが、翻訳上の誤りはあり得る。なお、訳語はSOAP1.1 日本語訳に基づいている。
Copyright© 2001 International Business Machines Corporation, Microsoft
この文書はSOAP1.1エンベロープ内でディジタル署名情報を運ぶためのSOAPヘッダ項目のシンタックスと処理規則を規定している。
この文書はWorld Wide Web Consortiumへの投稿(Submission Request、W3C Staff Commentを参照)である。すべての承認されたW3Cへの投稿の完全リストについては、Acknowledged Submissions to W3Cを参照してください。
この文書はW3Cから入手できるNOTEであり議論のためのみのものである。W3Cによるこのノートの公開はW3C、W3Cのチーム、あるいはW3C会員の支持を意味するものではない。このノートの準備にあたってW3Cはなんの編集上の統制も行っていない。この文書は作業中のものであり、任意の時点で他の文書によって更新、置換え、時代遅れなものにされてしまうかもしれない。
現在のW3Cの技術文書のリストは Technical Reports pageで見ることができる。
このノートの動機は、XMLディジタル署名シンタックス [XML-Signature]を用いて、SOAP 1.1メッセージ [SOAP]に署名 する標準的な手法を提案することである。この目的のためにSOAPヘッダ項目<SOAP-SEC:Signature>が定義されている。
また、SOAPヘッダにセキュリティ機能を付加するための拡張可能な名前空間の定義も 提案されている。拡張可能とは、この先スキーマに新しい要素を付加することが できるが、スキーマ内の要素は変わらないことを意味する。 いずれXML暗号化のような適切な標準が利用できるようになったときに、 他のセキュリティ機能がこの名前空間の下で付加されることを意図している。 我々が別のノートあるいはワーキンググループに特に任せたいことは、 SOAPのための認証プロトコルの定義である。プロトコルとは、 署名および暗号化されたメッセージの受信者による予期される処理を意味する。
文書中のキーワード "MUST(しなければならない)", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY(してもよい)", 及び "OPTIONAL" はRFC-2119 [KEYWORDS]の記述に従って解釈される。
一般に"some-URI"という形式の名前空間URIは、 いくつかのアプリケーション依存または文脈依存の RFC2396 [URI]で定義されている URIを表わす。 文書中の名前空間の接頭辞"SOAP-ENV"と"ds"は それぞれ名前空間 "http://schemas.xmlsoap.org/soap/envelope/"と "http://www.w3.org/2000/09/xmldsig#"に関連付けられている。
この規約の実装によって使用されなければならないXML名前空間 [XML-ns] URIは
http://schemas.xmlsoap.org/soap/security/2000-12
である。この規約で使われる名前空間接頭辞"SOAP-SEC"はこのURIに関連付けられている。
ヘッダ項目<SOAP-SEC:Signature>は以下のスキーマ [XML-Schema1], [XML-Schema2]により定義される。 <SOAP-SEC:Signature> 要素は XMLディジタル署名規約 [XML-Signature] に準拠する単一のディジタル署名情報を含む。
<schema
xmlns="http://www.w3.org/1999/XMLSchema"
xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
targetNamespace="http://schemas.xmlsoap.org/soap/security/2000-12"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<import namespace="http://www.w3.org/2000/09/xmldsig#"/>
<import namespace="http://schemas.xmlsoap.org/soap/envelope/"/>
<element name="Signature" final="restriction">
<complexType>
<sequence>
<element ref="ds:Signature" minOccurs="1" maxOccurs="1"/>
</sequence>
<attribute name="id" type="ID" use="optional"/>
<attribute ref="SOAP-ENV:actor" use="optional"/>
<attribute ref="SOAP-ENV:mustUnderstand" use="optional"/>
</complexType>
</element>
<attribute name="id" type="ID"/>
</schema>
|
<ds:Reference> 要素はSOAPエンベロープ内の署名されている部分を指定する 必要がある。これは、XML識別子を介して実現できる。 どの属性がID型であるかを決定するのはアプリケーションの責任である。 アプリケーションがID型属性を識別するのを助けるために、この規約では SOAP-SEC:id グローバル属性を定義している。この属性はSOAPエンベロープ内の 署名されている部分を指定するのに使われてもよい。
以下に署名ヘッダ項目をもつSOAPメッセージの例がある。ここでは、SOAP本体が 署名されており、その結果生成された署名 <ds:Signature> は <SOAP-SEC:Signature>ヘッダ項目に付加されている。 <ds:Reference> 要素の"URI"属性が<SOAP-ENV:SOAP-Body> 要素を指して いる点に注意されたい。
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<SOAP-SEC:Signature
xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
SOAP-ENV:actor="some-URI"
SOAP-ENV:mustUnderstand="1">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026">
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<ds:Reference URI="#Body">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>
</ds:Signature>
</SOAP-SEC:Signature>
</SOAP-ENV:Header>
<SOAP-ENV:Body
xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
SOAP-SEC:id="Body">
<m:GetLastTradePrice xmlns:m="some-URI">
<m:symbol>IBM</m:symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
Signatureヘッダ項目は、 SOAPエンベロープ内の一つ以上の要素に署名することを目的として、 そのSOAPエンベロープ内にてXMLディジタル署名規約 [XML-Signature] に準拠した 署名を運ぶために使用される。 複数の署名ヘッダ項目が単一のSOAPエンベロープに付加されてもよく、 それらは異なる要素を署名していてもよいし、重複する要素を署名していてもよい。 この規約の将来のバージョンは、<SOAP-SEC:Signature> の内容モデルの拡張(extension) [XML-Schema1] によりXMLディジタル署名以外の署名シンタックスの使用を許可するかもしれない。
この規約に準拠するSOAPアプリケーションは以下の条件を満たさなければならない。
mustUnderstand="1"属性によって強制されるか、あるいは、自発的に)、<ds:SignedInfo> および他の署名されるリソースのXML Canonicalization [XML-C14N] は、それ自身の文脈に従って処理されなければならないことに注意されたい。このことは、とりわけ、<ds:SigndInfo>のCanonical形式 [XML-C14N] は常にSOAP-ENVおよびSOAP-SECの名前空間宣言を継承することを意味する。
この章の残りでは署名ヘッダ項目に対して実行されるべき操作を記述している。
<SOAP-SEC:Signature>ヘッダ項目を作成する一つの方法は以下の処理である。
XMLディジタル署名規約 [XML-Signature] で述べられているように、署名されるオブジェクトを指定するためにXPathフィルタリングを使うことができる。しかしながら、SOAPのメッセージ交換モデルは中間(intermediate)アプリケーションがエンベロープを修正することを許可しているので(例えば、ヘッダ項目を追加したり削除したりする)、XPathフィルタリングの結果が、メッセージ配送後に、常に同じオブジェクトを指定するとは限らない。XPathフィルタリングを使用する場合には、そのような修正のせいでその後の署名検証の失敗が起こらないように注意されるべきである。
XMLディジタル署名規約 [XML-Signature] で定義されているhttp://www.w3.org/2000/09/xmldsig#enveloped-signature 変換は、他のヘッダ項目を含むエンベロープ全体を署名する場合に便利かもしれない。
<SOAP-SEC:Signature>の検証は以下の場合に失敗する。
もし署名ヘッダ項目の検証が失敗したなら、アプリケーションは送信者に失敗を報告してもよい。それをどのように扱うかはこの規約で扱う範囲外である。
この規約はSOAP1.1ヘッダでのXMLディジタル署名の利用を定義している。 SOAPメッセージのセキュリティを高めるための構成要素の一つとして、 他のセキュリティ技術といっしょに使用されることが意図されている。 ディジタル署名は共に利用される他のセキュリティメカニズムの状況および エンティティへの脅威に応じて理解される必要がある。 IETF RFC 2828[DIGSIG] によれば、 ディジタル署名とは、
「データの任意の受信者が、そのデータの作成元と完全性(integrity)を検証できるように、暗号アルゴリズムを用いて計算され、そのデータオブジェクトに付加される値(データ作成元認証サービス, データ完全性サービス、ディジタイズド署名、電子署名、署名者を参照)。」
「データ単位(data unit)の受信者がそのデータ単位の作成元と完全性を証明することができ、そして、例えば受信者による偽造から守ることができるような、データ単位に付加されるデータあるいはデータ単位の暗号変換。」[I7498Part2]
である。
例えば、ディジタル署名だけではメッセージ認証を提供しない。 誰かが、署名されたメッセージを記録し、それを再送できるからである（リプレー攻撃）。 この種の攻撃を防ぐために、ディジタル署名は、ナンス(nonces)やタイムスタンプの ようなメッセージの一意性を保証するための適切な手段と 組み合わされなければならない。この情報を付加する一つの方法は、 <ds:Signature>の子要素である<ds:Object> 要素を 余分に付け加えることである。
ディジタル署名が送信者の身元を検証するのに用いられるときは、 送信者は秘密鍵の所持を証明しなければならない。 これを実現する一つの方法は、チャレンジ・レスポンス型のプロトコルを 用いることである。
また、実装者は、一般的なデジタル署名や、特にこのXMLディジタル署名の利用から 生じるすべてのセキュリティの意味を知るべきである。 ディジタル署名に基づくアプリケーションで信頼(trust)を構築する際には、 署名と関連して認識されなければならない技術が他にいくつかある。 階層的であるにしろ、ピア・ツー・ピアであるにしろ、証明書の信頼モデルが 必要である。信頼できる鍵ペアと証明書を生成および管理する手段が必要である。 そして、証明書が失効していなことを検証する手段がなければならない。