Abstract
This document specifies XML digital signature processing rules
and syntax. XML Signatures provide integrity, message
authentication, and/or signer authentication services for data of any
type, whether located within the XML that includes the signature or
elsewhere.
Status of this
document
This document is a Proposed Recommendations (PR) of the W3C. The
IETF/W3C XML Signature
Working Group(W3C Activity
Statement) believes this specification addresses all
issues raised during Candidate Recommendation and its
specification is sufficient for the creation of independent
interopable implementations (see the Interoperability
Report).
W3C Advisory Committee Members are invited to send formal review
comments to the W3C Team until 17 September 2001 at xml-dsig-review@w3.org.The
public is invited to send comments to the editors and the public
mailing list w3c-ietf-xmldsig@w3.org
(archive
).
After the review the Director will announce the document's
disposition. This announcement should not be expected sooner than
14 days after the end of the review. Advancement (or even the
announcement) will not occur until the Director is confident of its
advancement to Draft Standard in the IETF.
Patent disclosures relevant to this specification may be found
on the Working Group's patent
disclosure page, in conformance with W3C policy, and the IETF Page of Intellectual
Property Rights Notices, in conformance with IETF policy.
Publication as a Proposed Recommendation does not imply
endorsement by the W3C membership. This is still a draft document
and may be updated, replaced or obsoleted by other documents at any
time. It is inappropriate to cite a W3C Proposed Recommendations as
other than a "work in progress." A list of current W3C
Recommendations and other technical documents can be found at http://www.w3.org/TR/.
目次
- イントロダクション
- 編集用の便宜
- 設計哲学
- バージョン、ネームスペース、識別子
- 謝辞
- 署名の概要およびサンプル
- 簡単な例
(
Signature, SignedInfo,
Methods, References )
-
Referenceの詳細
- 発展した例
(
Object と SignatureProperty)
- 発展した例 (
Object
と Manifest)
- 処理ルール
- 署名の生成
- 署名の検証
- コア 署名文法
Signature
エレメントSignatureValue
エレメントSignedInfo
エレメント
-
CanonicalizationMethod エレメント
SignatureMethod
エレメントReference エレメント
URI 属性- リファレンス処理モデル
- 同一ドキュメントのURI参照
Transforms
エレメントDigestMethod
エレメントDigestValue
エレメント
KeyInfo エレメント
KeyName
エレメントKeyValue
エレメント-
DSAKeyValue
エレメントRSAKeyValue
エレメント
RetrievalMethod
エレメントX509Data
エレメントPGPData
エレメントSPKIData
エレメントMgmtData
エレメント
Object エレメント
- 追加の署名文法
Manifest
エレメント-
SignatureProperties エレメント
- 処理命令
- dsigエレメント中のコメント
- アルゴリズム
- アルゴリズム識別子および実装の要求事項
- メッセージ・ダイジェスト
- メッセージ認証コード
- 署名アルゴリズム
- 正規化(Canonicalization) アルゴリズム
- 変換(Transform) アルゴリズム
- 正規化(Canonicalization)
- Base64
- XPath フィルタリング
- エンベロープされた署名変換
- XSLT変換
- スキーマ検証
- XML 正規化および文法の制約上の配慮
(Syntax Constraint Considerations)
- XML 1.0, 文法の制約, 正規化
- DOM/SAX 処理と正規化
- ネームスペースコンテキストとポータブルな署名
- セキュリティ上の配慮
- 変換について
- 署名されたもののみが安全である
- 「見られた」ものだけが署名されるべきである
- 何が署名されたかを「見なさい」
- セキュリティモデルをチェックしなさい
- アルゴリズム、鍵の長さ、etc.
- スキーマ, DTD, データモデル, 有効な例
- 定義
- 参考文献
- 著者のアドレス
このドキュメントは、電子署名の生成および表現に関するXML文法および処理ルールを規定する。
XML Signatureは、XMLを含め、いかなるデジタルコンテンツ (データオブジェクト)にも適用することができる。
1つのXML Signatureは、1つ以上のリソースの内容に適用されうる。
エンベロープされた あるいは エンベロープしている
署名は、署名としてのXMLドキュメントと一緒に入っている。
分離した 署名は、署名エレメントの外部にある。
さらに仕様的に言えば、この仕様はXML署名エレメント型とXML署名アプリケーション
を定義する。
それぞれの適合性の要求事項は、それぞれ、スキーマ定義および機械的定義(prose)によって規定される。
この仕様には、リソース、アルゴリズム、鍵および管理情報のコレクションを参照するメソッドを識別する、他の有用な型も含まれている。
XML Signatureは鍵と参照されるデータ（オクテット）を関連付ける方法である。これは、どのように鍵が人間あるいは機関と関連付けられるかについても、また、参照され署名されるデータの意味についても、規範的に規定することはない。
従って、この仕様が安全なXMLアプリケーションの重要なコンポーネントであるとしても、これ自身はアプリケーションの全てのセキュリティおよび信用に関して守備範囲とする(address)には不十分である。特に署名されたXML（あるいはその他のデータフォーマット）を人から人へのコミュニケーションおよび同意についての基礎とする場合はなおさらである。
このようなアプリケーションは、付加的な鍵、アルゴリズム、処理及びレンダリングの要求事項を明示(specify)しなければならない。
さらなる情報は、セキュリティへの配慮 (セクション 8)を参照していただきたい。
1.1 編集上の、
および適合性のための便宜
可読性、簡潔性、および歴史的な理由のため、このドキュメントでは「署名」という用語を、一般的に、全ての型に対するデジタル認証値を表すもの、として用いる。
明らかに、この用語は、厳密に、署名者の認証を公開鍵に基づいて提供する認証値を表すものとしても用いられる。
明示的に、認証値が対象秘密鍵コードに基づいていると議論していない限り、我々は認証者あるいは認証コードという用語を用いる。
(セキュリティモデルをチェックしなさい、セクション 8.3を参照。)
この仕様ではXML Schema [XML-schema] および DTD [XML]を提供する。
スキーマ定義は規範的である。
この仕様で用いられているキーワード"MUST"),"MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL"
は
RFC2119 [KEYWORDS]に記されている通りに解釈されることになる:
「それらは、これが実際にインターオペレーションあるいは障害を発生させる可能性がある振る舞いを制限する（たとえば再転送の制限）ために要求されるところでのみ用いられねばならない(MUST)」
ついては、我々はこれらの大文字で記されたキーワードを、プロトコル、およびアプリケーションの機能、およびインターオペラビリティに影響するような振る舞い、および実装のセキュリティについて、明確に要求事項を規定するために用いる。
これらのキーワードは、XML文法を説明する際には用いられない（大文字とならない）。
スキーマ定義で明確にそれらの要求事項を説明することとし、我々はこれらの用語の突出を、プロトコルおよび機能に関する自然言語での説明のために予約しておきたい。
たとえば、あるXML属性は「オプションである」と記述されるかもしれない。XMLネームスペース仕様[XML-ns] に準拠すると「必須である(REQUIRED)」と記述される。（誤訳の可能性あり）
1.2 設計哲学
この仕様の設計哲学および要求事項は、XML-Signature 要求事項のドキュメント [XML-Signature-RD]で言及されている。
1.3 バージョン、
ネームスペース、識別子
この文法では、明示的なバージョン番号は提供されない。もし将来のバージョンが必要になれば、それは異なるネームスペースを用いることになろう。
この（日付の）仕様の実装によって用いられねばならない(MUST)
XMLネームスペース [XML-ns] URIは:
xmlns="http://www.w3.org/2000/09/xmldsig#"
この仕様において、このネームスペースはアルゴリズム識別子のプレフィックスとしても用いられる。
アプリケーションはXMLおよびXMLネームスペースをサポートせねばならない(MUST)が、
内部実体 [XML] あるいは我々の "dsig" XML ネームスペースプレフィックス およびデフォルトの/スコープの便宜(conventions)の仕様は任意(OPTIONAL)である。
我々はこれらの機能(facilities)を、コンパクトで可読性の高い例として提供する。
この仕様では、リソース、アルゴリズム、セマンティクスを識別するために、統一リソース識別子 [URI] を用いる。
上記のネームスペース宣言におけるURIは、この仕様の支配下にあるURIのためのプレフィックスにも用いられる。
この仕様の支配下にないリソースについては、我々はこの規範的な外部仕様で定義された統一リソース名 [URN] あるいは統一リソースロケータ [URL] を用いる。
もし外部仕様がURIを獲得していなければ、我々が独自のネームスペースの下で識別子を獲得する。たとえば:
SignatureProperties は、この仕様のネームスペースによって識別され定義される- http://www.w3.org/2000/09/xmldsig#SignatureProperties
- XSLT は、外部URIによって識別され定義される
- http://www.w3.org/TR/1999/REC-xslt-19991116
- SHA1 は、この仕様のネームスペースによって識別され、規範的な参照を通じて定義される
- http://www.w3.org/2000/09/xmldsig#sha1
- FIPS PUB 180-1. Secure Hash Standard. U.S. Department of
Commerce/National Institute of Standards and Technology.
最後に、簡潔なネームスペース宣言を提供するために、我々はしばしばURIの中でXML 内部実体 [XML] を用いる。たとえば:
<?xml version='1.0'?>
<!DOCTYPE Signature SYSTEM
"xmldsig-core-schema.dtd" [ <!ENTITY dsig
"http://www.w3.org/2000/09/xmldsig#"> ]>
<Signature xmlns="&dsig;" Id="MyFirstSignature">
<SignedInfo>
...
この仕様に関する以下のワーキンググループメンバーに感謝する:
- Mark Bartel, JetForm Corporation (Author)
- John Boyer, PureEdge (Author)
- Mariano P. Consens, University of Waterloo
- John Cowan, Reuters Health
- Donald Eastlake 3rd, Motorola (Chair, Author/Editor)
- Barb Fox, Microsoft (Author)
- Christian Geuer-Pollmann, University Siegen
- Tom Gindin, IBM
- Phillip Hallam-Baker, VeriSign Inc
- Richard Himes, US Courts
- Merlin Hughes, Baltimore
- Gregor Karlinger, IAIK TU Graz
- Brian LaMacchia, Microsoft (Author)
- Peter Lipp, IAIK TU Graz
- Joseph Reagle, W3C (Chair, Author/Editor)
- Ed Simon (Author)
- David Solo, Citigroup (Author/Editor)
- Petteri Stenius, DONE Information, Ltd
- Raghavan Srinivas, Sun
- Kent Tamura, IBM
- Winchel Todd Vincent III, GSU
- Carl Wallace, Corsec Security, Inc.
- Greg Whitehead, Signio Inc.
以下、最終審判(last call)コメントに関して:
このセクションではXML電子署名文法の概要と例を示す。
仕様としての処理は
処理ルール (セクション 3)にある。
形式的な文法はコア署名文法 (セクション 4) およびさらなる署名文法
(セクション 5)にある。
このセクションでは、非公式の表現および例が、XML署名文法の構造を説明するのに用いられている。これらの表現および例は、その後で説明する属性や詳細や潜在的な機能について、省略していることがある。
XML Signatureは、間接指定(indirection)を用いて、任意の
デジタルコンテンツ(データオブジェクト) に適用することが出来る。
データオブジェクトはダイジェスト化され、その結果となる値は1つのエレメントに（他の情報とともに）配置され、よってそのエレメントはダイジェスト化され暗号によって署名されたことになる。
XML電子署名は、以下のような構造を持つ
Signature
エレメントによって表される
("?"は0回または1回の出現を、"+"は1回以上の出現を、"*"は0回以上の出現を表す):
<Signature>
<SignedInfo>
(CanonicalizationMethod)
(SignatureMethod)
(<Reference (URI=)? >
(Transforms)?
(DigestMethod)
(DigestValue)
</Reference>)+
</SignedInfo>
(SignatureValue)
(KeyInfo)?
(Object)*
</Signature>
署名はURI [URI] を通じて、データオブジェクト に関連付けられる。
XMLドキュメント内では、署名はフラグメント識別子を通じて、ローカルデータオブジェクトに関連付けられる。
このようなローカルデータは、
エンベロープする 署名内に含まれたり、
signature or can enclose an エンベロープされた
署名を包含したりすることがある。
分離された署名 は、外部ネットワークリソースあるいは同じXMLドキュメント内に兄弟エレメントとして存在するローカルデータオブジェクトに対するものである。この場合、この署名はエンベロープする（署名が親）ものでもなければ、エンベロープされた（署名が子）ものでもない。
Signature エレメント (およびその
Id 属性の値/名前) が、単一のXMLドキュメント中の他のエレメント（およびそのID）と共存(co-exist)あるいは連結(combine)しうるため、
ID 一意性が有効であるという制約 [XML]に違反するような衝突を結果的に生じないように名前を選択するような注意がなされなければならない。
2.1 簡単な例
(Signature, SignedInfo,
Methods, References)
以下の例は、XML仕様によるHTML4（訳注: XHTMLの仕様書）の内容の、分離された署名である。
[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">
[s02] <SignedInfo>
[s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s08] </Transforms>
[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11] </Reference>
[s12] </SignedInfo>
[s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
[s14] <KeyInfo>
[s15a] <KeyValue>
[s15b] <DSAKeyValue>
[s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y>
[s15d] </DSAKeyValue>
[s15e] </KeyValue>
[s16] </KeyInfo>
[s17] </Signature>
[s02-12] 必須の SignedInfo
エレメントは、実際に署名したときの情報である。
SignedInfoの
コア検証 は、
2つの主要なプロセスからなる:
SignedInfo に対する
署名の検証 と
SignedInfo 中の
それぞれの
Referenceダイジェストの検証である。
注意すべきは、
SignatureValue エレメントは
SignedInfoの外側にあるが、
SignatureValue を計算するために用いられたアルゴリズムもまた、署名情報の中に含まれる、という点である。
[s03] CanonicalizationMethod は、
署名命令の一部としてダイジェスト化される前に
SignedInfo エレメントを正規化するために用いられたアルゴリズムである。
この例およびこの仕様における全ての例は、正規化された形式ではないということに注意。
[s04] SignatureMethod は
SignatureValue
の中に
正規化されたSignedInfo をコンバートするために用いられるアルゴリズムである。
これは、例えばRSA-SHA1のような、ダイジェスト・アルゴリズム、および鍵依存のアルゴリズム、および可能性としてはパディングのようなその他のアルゴリズムである。
このアルゴリズム名は、代替となるより弱いアルゴリズムに基づいて、攻撃に耐えるために署名される。アプリケーションのインターオペラビリティを促進するために、我々は実装されねばならない(MUST)署名アルゴリズムの集合を用いる。それらの使用は署名作成者の裁量による。我々は追加のアルゴリズムを、実装の推奨(RECOMMENDED)ないし任意(OPTIONAL)として規定する。それらの設計は任意のユーザー指定のアルゴリズムを許容する。
[s05-11] それぞれの Reference エレメントは、ダイジェスト化メソッドと、識別されたデータオブジェクトについて計算された結果となるダイジェスト値を含む。
これはダイジェスト命令への入力を生成した変換(transformation)を含むこともある。
データオブジェクトは、そのダイジェスト値およびその値に対する署名を計算することによって署名される。
この署名は後でreference および
署名検証を通じて確認される。
[s14-16] KeyInfo は、署名を検証するために用いる鍵を示す。識別のために考えうる形式では、証明書、鍵の名前、鍵合意法(key agreement algorithm)および情報が含まれる -- 我々は少しだけ定義している。
KeyInfo は、2つの理由からオプションとなっている。まず、署名者は鍵の情報を全てのドキュメント処理パーティに公開したくないかもしれない。そして、この情報はアプリケーションのコンテキストにとって既知であり、明示的に表現される必要がないかもしれない。
KeyInfo は
SignedInfo
の外側にあるので、もし署名者が鍵情報を署名に結びつけたいと思ったら、
Reference は簡単に識別でき、また署名の中の一部として
KeyInfo を含めることができる。
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s08] </Transforms>
[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11] </Reference>
[s05] オプションとなる Reference の
URI 属性は、署名されるデータオブジェクトを識別する。
この属性はSignature中の、最大1つの Reference
についてのみ、省略できる。
（この制限は、参照およびオブジェクトが明確にマッチすることを保証するためである。）
[s05-08] この識別は、変換とともに、署名者がどのようにダイジェスト化された形の署名付きデータオブジェクトを（つまりダイジェスト化されたコンテンツを）獲得したか、について、署名者から提供される記述である。
検証者は、ダイジェスト化されたコンテンツを、ダイジェストが検証する限りの他の方法で、獲得することもありうる。
特に、検証者はコンテンツを、URIで指定された場所ではなく、ローカルの情報蓄積のような、別のロケーションから獲得するかもしれない。
[s06-08] Transforms は、オプションとなる、ダイジェスト化される前に、リソースの内容に適用される処理のステップの、順序付けられたリストである。
変換には、正規化、エンコーディング／デコーディング（圧縮／展開）、XSLT、XPath、XMLスキーマ検証、あるいはXIncludeのような、命令が含まれうる。
XPath変換は、署名者がソースドキュメントの一部分を省いたようなXMLドキュメントを引っ張り出すことを可能にする。
よって、これらの排除された部分は、署名の有効性に影響することなく変更することができる。
例えば、もし署名されたリソースが署名自身を囲む場合、署名の値をそれ自身の計算から排除するような変換が用いられなければならない。
もし
Transforms エレメントが存在しない場合、そのリソースの内容は直接ダイジェスト化される。
このワーキンググループは、必須の（そしてオプションの）正規化およびデコーディングアルゴリズムを規定しているが、ユーザー指定の変換も許されている。
[s09-10] DigestMethod は、
Transforms
が（指定されていれば）適用された後に、
DigestValue
を作成するために、データに適用されるアルゴリズムである。
DigestValue の署名は、署名者の鍵とリソース内容とを結びつける。
この仕様は記述(statements)あるいは宣言(assertions)を行うメカニズムについて言及しない。
その代わり、このドキュメントでは、XML Signatureによって署名されたものにとって重要なことを定義する（完全性, メッセージ認証, そして 署名者の認証）。
他のセマンティクスを表現したいというアプリケーションは、他の技術、たとえば
[XML, RDF]などに依存しなければならない。
たとえば、アプリケーションは、
Signature エレメントを参照するために、
自分自身のマークアップの内部に
foo:assuredby
属性を用いるであろう。
従って、その署名の検証とassuredby文法の意味を与えられて、その信用決定を行う方法を、理解して知っていなければならないのは、そのアプリケーションである。
我々はまた、
We also define a SignatureProperties エレメント型を、署名自身についての宣言(assertions)の包含のために定義する（たとえば、署名のセマンティクスであるとか、署名時刻であるとか、暗号処理に用いられたハードウェアのシリアル番号であるとか）。
それらの宣言は
SignedInfo 中の
SignatureProperties への
Reference を含むことで署名することができる。
署名アプリケーションは、それが署名するもの（SignatureProperty 中にあるものを理解すべきである）について、受信するアプリケーションはそのセマンティクスを理解する義務が無い（たとえその親の信用エンジンが望んだとしても）ということを、十分に配慮すべきである。
署名生成にかかるいかなるコンテンツも、
SignatureProperty エレメントの中でロケートできるかもしれない。
必須の Target 属性は、
そのプロパティが適用される
Signature エレメントを参照する。（うわーここ無茶苦茶だな。妥当な翻訳はしばらく待ってください）
先の例に、SignatureProperty エレメントを含む
ローカルの
Object
への参照が追加されたものを考えてみてほしい。
（このような署名は 分離された [p02] ものに限らず、エンベロープする
[p03]ものもそうである。)
[ ] <Signature Id="MySecondSignature" ...>
[p01] <SignedInfo>
[ ] ...
[p02] <Reference URI="http://www.w3.org/TR/xml-stylesheet/">
[ ] ...
[p03] <Reference URI="#AMadeUpTimeStamp"
[p04] Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">
[p05] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[p06] <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[p07] </Reference>
[p08] </SignedInfo>
[p09] ...
[p10] <Object>
[p11] <SignatureProperties>
[p12] <SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature">
[p13] <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">
[p14] <date>19990908</date>
[p15] <time>14:34:34:34</time>
[p16] </timestamp>
[p17] </SignatureProperty>
[p18] </SignatureProperties>
[p19] </Object>
[p20]</Signature>
[p04]
Reference のオプションとなる Type 属性は、
URIによって識別されるリソースについての情報を提供する。
特に、これはエレメントがObjectであるか、SignaturePropertyであるか、Manifest のであるかを示す。
これは、アプリケーションがいくつかのReference
エレメントに特別な処理を行うために用いることも可能である。
Object エレメント内のXMLデータエレメントへの参照は、示された実際のエレメントを識別すべきである(SHOULD)。
エレメントの内容がXMLでない場合（おそらくバイナリあるいはエンコードされたデータであろう）、その参照は、Object を識別すべきであり、そしてもしあれば Reference
Typeは Objectを識別すべきである(SHOULD)（後者のみRFC規定の用語）。
Type は補助にすぎず、これに基づくアクションあるいはその正しさのチェックは、コアとなる振る舞いには必須とされていないことに注意。
[p10] Object は、データオブジェクトを署名エレメントあるいはその他に含めるための、オプションとなるエレメントである。
Object はオプションによって、型付けされたりエンコードされたりすることができる。
[p11-18] 署名時刻など、署名のプロパティは、オプションとして、
Referenceの内部でそれらを識別することで署名されうる。
（これらのプロパティは伝統的に署名「属性」と呼ばれていた。XMLの用語である「属性」とは何の関わりも無いが。）
2.3 発展した例 (Object および Manifest)
Manifest エレメントは、付加的な要求事項を満足するために、この仕様の必須の部分を直接的に記述しないものとして提供される。
2つの要求事項と
Manifest がそれを満足する方法を、これから説明する。
まず、アプリケーションはしばしば、公開鍵署名そのものが重い(expensive)にもかかわらず、効率的に複数のデータオブジェクトに署名する必要がある。
この要求事項は、
複数のReference エレメントを
SignedInfo
の中に含めることで満足できる。
なぜなら、それぞれのダイジェストを含めることで、データのダイジェストが安全になるからである。
しかし、いくつかのアプリケーションでは、
SignedInfo 中の全ての
Reference に、
水面下で
参照解析
を行うことを要求するので、
コア検証
の振る舞いをこのアプローチと関連付けたくないかもしれない。
DigestValue
エレメントはチェックされる。
これらのアプリケーションは参照解析判断ロジックを自身で保持したいと望むかもしれない。
たとえば、署名の値
3つの Reference エレメントを含む
SignedInfo
エレメントを受け取るかもしれない。
もし1つでもReference が失敗したら（その識別されたデータオブジェクトがダイジェスト化されたとき、指定された
DigestValueに一致しなかった場合）、その署名のコア検証は失敗とされる。
しかし、アプリケーションはその署名を、2つの有効な
Reference エレメントについては有効であると扱いたいかもしれないし、どれが失敗したかに依存して異なるアクションを起こしたいかもしれない。
これを達成するために、
SignedInfo は
1つ以上の Reference エレメントを（SignedInfoにあるものと同じ構造で）含む Manifest エレメントを参照する。
従って、
Manifest の参照の検証は、アプリケーション制御の下にある。
次に、多くの署名（異なる鍵を用いる）が数多くのドキュメントに適用されるようなアプリケーションを考えてほしい。
巨大な
SignedInfo
エレメント（そして多くのReference）に、独立した署名を（鍵ごとに）何度も適用されるというのは、満足できる解とはいえない。無駄であり冗長である。
より適切な解は、多くの参照を単一の
Manifest に含めるというものである。この場合、これは
複数の
Signature
エレメントから参照されるということになる。
以下の例は、Object エレメントの中にある Manifest に署名するための Reference を含んでいる。
[ ] ...
[m01] <Reference URI="#MyFirstManifest"
[m02] Type="http://www.w3.org/2000/09/xmldsig#Manifest">
[m03] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[m04] <DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[m05] </Reference>
[ ] ...
[m06] <Object>
[m07] <Manifest Id="MyFirstManifest">
[m08] <Reference>
[m09] ...
[m10] </Reference>
[m11] <Reference>
[m12] ...
[m13] </Reference>
[m14] </Manifest>
[m15] </Object>
3.0 処理
ルール
このセクション以降は、署名の生成および検証の一部分として実行すべき命令について説明する。
3.1 生成コア
Reference エレメントと
SignedInfo に対する
SignatureValue の生成は
必須となる(REQUIRED)ステップに含まれる。
署名されるそれぞれのデータオブジェクトについて:
- アプリケーションによって決定された通りに、データオブジェクトに対して
Transformsを適用する。
- その結果となるデータオブジェクトに対して、ダイジェスト値を計算する。
Reference エレメントを生成する。その中には（オプションで）データオブジェクトの識別子と、（オプションで）変換エレメントと、ダイジェストアルゴリズムと
DigestValue が含まれる。
（それら、3.1.2の方法で署名され、3.2.1の方法で検証される参照は、正規化された形である。）
-
SignedInfo エレメントを、
SignatureMethod, CanonicalizationMethod,
Reference と一緒に生成する。
-
SignedInfoで指定した通りのアルゴリズムで、
SignedInfo を正規化し、その
SignatureValue を計算する。
-
SignedInfo, Object
（もし望むなら、エンコーディングは署名に用いたものと異なっても良い）,
KeyInfo
（もし必要なら）, そして
SignatureValue を含む
Signature エレメントを構築する。
3.2 検証コア
検証コア には (1) 参照の検証、すなわち
SignedInfo
中のそれぞれの
Reference に含まれる
ダイジェストの検証と、
(2) SignedInfo
に対して計算された署名の、暗号理論による 署名の検証
が、必須の(REQUIRED)ステップとして含まれる。
一部の署名アプリケーションが検証できないが有効な署名というものも存在しうることに注意。
その理由は、この仕様でオプションである部分を実装しなかった場合や、指定されたアルゴリズムを実行できない、あるいはしたくない場合、指定されたURIを参照展開(dereference)できない、あるいはしたくない場合（ある種のURIスキームは予期しない副次的効果を引き起こしうる）などである。
参照値の比較および署名の検証は、数値的に（たとえば整数で）、あるいはデコードされた値の一連のオクテットとして、行われる。
異なる実装の間では、同じリソースを処理する際に、エンコーディングのバリエーションのために、たとえば付帯的な空白文字のために、異なるエンコードダイジェストと署名の値を生成するかもしれない。
しかし、もし数値あるいはオクテット（のいずれか）を、記載された値と計算された値の両方に用いれば、この問題は無視できる。
-
SignedInfo 中の CanonicalizationMethod に基づいて、
SignedInfo エレメントを正規化する。
SignedInfo
中のそれぞれのReference について:
- ダイジェスト化するデータオブジェクトを取得する。（たとえば、署名アプリケーションは、
URI を参照解除(dereference)して、Reference エレメント中に署名者が用意したTransforms を実行したり、あるいはローカルキャッシュのようなものを通じてコンテンツを取得したりするかもしれない。）
- その結果となるデータオブジェクトに、
Reference が指定した
DigestMethod を用いてダイジェスト化する。
- 生成されたダイジェスト値を、
SignedInfo の Reference 中の DigestValue と比較する。
もし相違点があれば、検証は失敗である。
SignedInfo
はステップ1で正規化される。
アプリケーションは、正規化メソッドが、URIの書き換え（CanonicalizationMethod
(セクション 4.3)を参照）など危険な副作用をもたないことや、正規化された形で署名されたものを見る（ことができる）ことを、保証しなければならない。
- 鍵の情報を
KeyInfo あるいは外部の情報源から取得する。
CanonicalizationMethod を用いて
SignatureMethod の正規化された形を取得し、
その結果（およびその前に取得した KeyInfo）を用いて
SignedInfo エレメントに対する
SignatureValue を確認する。
KeyInfo （あるいはそれらの変形されたバージョン）は
Reference エレメントを通じて署名されているかもしれないということに注意。
参照の変換および検証(3.2.1) は、
解析された KeyInfo を用いる署名検証とは独立している(orthogonal)。
さらに、SignatureMethod URI は
SignedInfo
の正規化によって変わっているかもしれない（たとえば相対URIの絶対化など）し、
正規化された形式が用いられなければならない(MUST)。
しかし、この仕様で要求される正規化 [XML-C14N] では、URIを変更しない。
XML署名の一般的な構造は、署名概要 (セクション 2)で説明される。
このセクションでは、コア署名機能の詳細な文法を示す。
このセクションで説明される機能は、特に明記しない限り、実装する必要があるものとする。
この文法はDTDおよび [XML-Schema]
で、以下のXMLの序文、宣言、および内部実体とともに定義されている。
Schema Definition:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema
PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd"
[
<!ATTLIST schema
xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
<!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'>
<!ENTITY % p ''>
<!ENTITY % s ''>
]>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="http://www.w3.org/2000/09/xmldsig#"
version="0.1" elementFormDefault="qualified">
DTD:
<!--
The following entity declarations enable external/flexible content in
the Signature content model.
#PCDATA emulates schema:string; when combined with element types it
emulates schema mixed="true".
%foo.ANY permits the user to include their own element types from
other namespaces, for example:
<!ENTITY % KeyValue.ANY '| ecds:ECDSAKeyValue'>
...
<!ELEMENT ecds:ECDSAKeyValue (#PCDATA) >
-->
<!ENTITY % Object.ANY ''>
<!ENTITY % Method.ANY ''>
<!ENTITY % Transform.ANY ''>
<!ENTITY % SignatureProperty.ANY ''>
<!ENTITY % KeyInfo.ANY ''>
<!ENTITY % KeyValue.ANY ''>
<!ENTITY % PGPData.ANY ''>
<!ENTITY % X509Data.ANY ''>
<!ENTITY % SPKIData.ANY ''>
4.0.1 The ds:CryptoBinary Simple Type
この仕様では ds:CryptoBinary
単純型を、任意の長さの整数（たとえば「巨大数」）をXMLでオクテット文字列として表すもの、と定義する。
この整数値はまず「ビッグエンディアン」ビット列に変換される。このビット列は、その後、ビットの総数 == 0 mod 8 となるように、先頭から0のビットをパディングされる
（そうやって、オクテットからなる1つの整数になる）。
もしそのビット列が、0になるような完全なリーディングオクテットを含む場合、それらは（高位のオクテットが常に非ゼロとなるように）削除される。
その後、このオクテット列は
base64 [MIME] エンコードされる。
（整数からオクテット列への変換は、最低の長さをもつIEEE 1363の I20SP [1363] に等しい。）
この型は RSAKeyValue や DSAKeyValue
など「巨大数」の値に用いられる。
もし値が base64Binary あるいは ds:CryptoBinary の型になりうる場合、それらはbase64Binary で定義される。
例えば、もし署名アルゴリズムが RSA あるいは DSA である場合、
SignatureValue は巨大数を表し、ds:CryptoBinaryとなるであろう。
しかし、もし HMAC-SHA1 が署名アルゴリズムであれば、
SignatureValue
は、予定されていなければならない先導するゼロのオクテットをもちうる。
こうして、SignatureValue は一般に base64Binary 型として定義されるのである。
Schema Definition:
<simpleType name="CryptoBinary">
<restriction base="base64Binary">
</restriction>
</simpleType>
Signature エレメントは XML
Signature のルートエレメントである。
実装は
文法的にスキーマ適合する [XML-schema]
Signature エレメントを、以下のスキーマの指定する通りに生成しなければならない[MUST]:
Schema Definition:
<element name="Signature" type="ds:SignatureType"/>
<complexType name="SignatureType">
<sequence>
<element ref="ds:SignedInfo"/>
<element ref="ds:SignatureValue"/>
<element ref="ds:KeyInfo" minOccurs="0"/>
<element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
DTD:
<!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*) >
<!ATTLIST Signature
xmlns CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'
Id ID #IMPLIED >
SignatureValue エレメントには、デジタル署名の実際の値が含まれる。
これは常に [MIME] を用いてエンコードされる。
2つの
SignatureMethod
アルゴリズムを区別する。一方は実装が必須であるもの、もう一方は任意であるものである。ユーザー指定のアルゴリズムも同様に用いられる。
Schema Definition:
<element name="SignatureValue" type="ds:SignatureValueType"/>
<complexType name="SignatureValueType">
<simpleContent>
<extension base="base64Binary">
<attribute name="Id" type="ID" use="optional"/>
</extension>
</simpleContent>
</complexType>
DTD:
<!ELEMENT SignatureValue (#PCDATA) >
<!ATTLIST SignatureValue
Id ID #IMPLIED>
SignedInfo の構造には、正規化アルゴリズム、署名アルゴリズム、1つ以上の参照が含まれる。
このSignedInfo エレメントは、オプションとなる、他の署名およびオブジェクトから参照されるための ID 属性をもつかもしれない。
SignedInfo は明示的な署名あるいはダイジェストプロパティ（計算時間、暗号化デバイス、シリアル番号などのようなもの）を含まない。
もしアプリケーションがプロパティを署名あるいはダイジェストに関連付ける必要があれば、そのような情報を Object
エレメント中の
SignatureProperties エレメント中に含めても良い。
Schema Definition:
<element name="SignedInfo" type="ds:SignedInfoType"/>
<complexType name="SignedInfoType">
<sequence>
<element ref="ds:CanonicalizationMethod"/>
<element ref="ds:SignatureMethod"/>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
DTD:
<!ELEMENT SignedInfo (CanonicalizationMethod,
SignatureMethod, Reference+) >
<!ATTLIST SignedInfo
Id ID #IMPLIED
CanonicalizationMethod は、署名計算を実行する前に
SignedInfo エレメントに適用する正規化アルゴリズムを指定する、必須のエレメントである。
このエレメントは、アルゴリズム識別子および実装の要求事項 (セクション 6.1)
で説明するアルゴリズムのための、一般的な構造を用いる。
実装は、必須(REQUIRED)の正規化アルゴリズムをサポートしなければならない。
必須(REQUIRED)の正規化アルゴリズム (セクション 6.5)の代わりに、
コメントを伴う正規のXML
(セクション 6.5.1) や最低限の正規化(minimal canonicalization)（改行および文字セットの正規化(normalization)など）は、明示的に規定されるが、必須ではない(NOT REQUIRED)。
従って、それらの使用は、指定されたアルゴリズムをサポートしない他のアプリケーションと相互動作しないかもしれない（XML の正規化および文法制約の考慮, セクション 7を参照）。
もし非XML対応の正規化アルゴリズムが適切に制約されていなければ、セキュリティ上の問題が、実体およびコメントの処理について生じることもある（
セクション 8.2: 「見られた」ものだけが署名されるべきである を参照）。
SignedInfo エレメントが正規化メソッドによって表される方法は、
その方法に依存している。以下が、XMLをノードあるいは文字として処理するアルゴリズムに適用される:
- XMLベースの正規化の実装は、
SignedInfo を含むドキュメントから形成されたもので、
現在はSignedInfo と、その子孫と、その SignedInfo の属性およびネームスペースのノードと、その子孫エレメント（重複？）を示すような、
[XPath] ノードセットを渡されなければならない(MUST)。
- （CRLFおよび文字セットの正規化のような）テキストベースの正規化アルゴリズムには、
ウェルフォームドな SignedInfo エレメントを表す、最初の文字から最後の文字までをXML表現として含むような、UTF-8オクテットを渡すべきである。
これには SignedInfo エレメントの開始タグと終了タグの完全なテキストが、それらのタグの間にあって子孫となるマークアップおよび文字データ （つまりテキスト）とともに含まれる。
SignedInfo のテキストベースの正規化の利用は推奨できない(NOT RECOMMENDED)。
我々は、XMLベースの正規化を実装せずにテキストベースの正規化を選ぶような、リソースに制約のあるアプリケーションは、インターオペラビリティとセキュリティの問題を緩和するために、正規化されたXMLをそれらのシリアライゼーションとするように実装することを推奨する。
たとえば、そのような実装は、（少なくとも）スタンドアロン XML
インスタンス [XML] を生成すべき(SHOULD)である。
備考: 署名アプリケーションは、任意の
CanonicalizationMethod を、大いに注意して受容し実行しなければならない。
たとえば、その正規化メソッドはURIを
References のURIを、有効なものとして書き換えるかもしれない。
あるいは、そのメソッドは
SignedInfo を大規模に変換してしまって、検証が常に成功するようにしてしまうかもしれない（すなわち、小さなデータに対して、小さな署名にコンバートすることで、鍵を判明させてしまうかもしれない）。
CanonicalizationMethod は
SignedInfoの中にあるので、結果となる正規形の中では、これは
SignedInfo から自身を消去することもできるし、
or modify the
SignedInfo エレメントを、異なる正規化関数が用いられたと見えるように修正してしまうかもしれない!
こうして、希望するデータを、希望する鍵と DigestMethod と SignatureMethod とで認証したい Signature は、おかしな
CanonicalizationMethod が使われると意味が無くなってしまうことがありうる。
Schema Definition:
<element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/>
<complexType name="CanonicalizationMethodType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) namespace -->
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
DTD:
<!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY;)* >
<!ATTLIST CanonicalizationMethod
Algorithm CDATA #REQUIRED >
SignatureMethod is a required element that
specifies the algorithm used for signature generation and
validation. This algorithm identifies all cryptographic functions
involved in the signature operation (e.g. hashing, public key
algorithms, MACs, padding, etc.). This element uses the general
structure here for algorithms described in section 6.1: Algorithm Identifiers and Implementation
Requirements. While there is a single identifier, that
identifier may specify a format containing multiple distinct
signature values.
Schema Definition:
<element name="SignatureMethod" type="ds:SignatureMethodType"/>
<complexType name="SignatureMethodType" mixed="true">
<sequence>
<element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) external namespace -->
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
DTD:
<!ELEMENT SignatureMethod (#PCDATA|HMACOutputLength %Method.ANY;)* >
<!ATTLIST SignatureMethod
Algorithm CDATA #REQUIRED >
Reference is an element that may occur one or more
times. It specifies a digest algorithm and digest value, and
optionally an identifier of the object being signed, the type of
the object, and/or a list of transforms to be applied prior to
digesting. The identification (URI) and transforms describe how the
digested content (i.e., the input to the digest method) was
created. The Type attribute facilitates the processing
of referenced data. For example, while this specification makes no
requirements over external data, an application may wish to signal
that the referent is a Manifest. An optional ID
attribute permits a Reference to be referenced from
elsewhere.
Schema Definition:
<element name="Reference" type="ds:ReferenceType"/>
<complexType name="ReferenceType">
<sequence>
<element ref="ds:Transforms" minOccurs="0"/>
<element ref="ds:DigestMethod"/>
<element ref="ds:DigestValue"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
<attribute name="URI" type="anyURI" use="optional"/>
<attribute name="Type" type="anyURI" use="optional"/>
</complexType>
DTD:
<!ELEMENT Reference (Transforms?, DigestMethod, DigestValue) >
<!ATTLIST Reference
Id ID #IMPLIED
URI CDATA #IMPLIED
Type CDATA #IMPLIED>
4.3.3.1 The URI
Attribute
The URI attribute identifies a data object using a
URI-Reference, as specified by RFC2396 [URI]. The set of allowed characters for
URI attributes is the same as for XML, namely [Unicode]. However, some Unicode characters
are disallowed from URI references including all non-ASCII
characters and the excluded characters listed in RFC2396 [URI, section 2.4]. However, the number sign
(#), percent sign (%), and square bracket characters re-allowed in
RFC 2732 [URI-Literal] are
permitted. Disallowed characters must be escaped as follows:
- Each disallowed character is converted to [UTF-8] as one or more octets.
- Any octets corresponding to a disallowed character are escaped
with the URI escaping mechanism (that is, converted to %HH, where
HH is the hexadecimal notation of the octet value).
- The original character is replaced by the resulting character
sequence.
XML signature applications MUST be able to parse URI syntax. We
RECOMMEND they be able to dereference URIs in the HTTP scheme.
Dereferencing a URI in the HTTP scheme MUST comply with the
Status Code Definitions of [HTTP]
(e.g., 302, 305 and 307 redirects are followed to obtain the
entity-body of a 200 status code response). Applications should
also be cognizant of the fact that protocol parameter and state
information, (such as HTTP cookies, HTML device profiles or content
negotiation), may affect the content yielded by dereferencing a
URI.
If a resource is identified by more than one URI, the most
specific should be used (e.g.
http://www.w3.org/2000/06/interop-pressrelease.html.en instead of
http://www.w3.org/2000/06/interop-pressrelease). (See the Reference Validation (section 3.2.1)
for a further information on reference processing.)
If the URI attribute is omitted altogether, the
receiving application is expected to know the identity of the
object. For example, a lightweight data protocol might omit this
attribute given the identity of the object is part of the
application context. This attribute may be omitted from at most one
Reference in any particular SignedInfo,
or Manifest.
The optional Type attribute contains information about the type
of object being signed. This is represented as a URI. For
example:
Type="http://www.w3.org/2000/09/xmldsig#Object"
Type="http://www.w3.org/2000/09/xmldsig#Manifest"
The Type attribute applies to the item being pointed at, not its
contents. For example, a reference that identifies an
Object element containing a
SignatureProperties element is still of type
#Object. The type attribute is advisory. No validation
of the type information is required by this specification.
The data-type of the result of URI dereferencing or subsequent
Transforms is either an octet stream or an XPath node-set.
The Transforms specified in this document are defined with
respect to the input they require. The following is the default
signature application behavior:
- If the data object is an octet stream and the next transform
requires a node-set, the signature application MUST attempt to
parse the octets yielding the required node-set.
- If the data object is a node-set and the next transform
requires octets, the signature application MUST attempt to convert
the node-set to an octet stream using the specified
canonicalization algorithm.
Users may specify alternative transforms that override these
defaults in transitions between Transforms that expect different
inputs. The final octet stream contains the data octets being
secured. The digest algorithm specified by
DigestMethod is then applied to these data octets,
resulting in the DigestValue.
Unless the URI-Reference is a 'same-document' reference as
defined in [URI, Section 4.2], the result of
dereferencing the URI-Reference MUST be an octet stream. In
particular, an XML document identified by URI is not parsed by the
signature application unless the URI is a same-document reference
or unless a transform that requires XML parsing is applied (See Transforms (section 4.3.3.1).)
When a fragment is preceded by an absolute or relative URI in
the URI-Reference, the meaning of the fragment is defined by the
resource's MIME type. Even for XML documents, URI dereferencing
(including the fragment processing) might be done for the signature
application by a proxy. Therefore, reference validation might fail
if fragment processing is not performed in a standard way (as
defined in the following section for same-document references).
Consequently, we RECOMMEND that the URI
attribute not include fragment identifiers and that such processing
be specified as an additional XPath
Transform.
When a fragment is not preceded by a URI in the URI-Reference,
XML signature applications MUST support the null URI and barename
XPointer. We RECOMMEND support for the same-document XPointers
'#xpointer(/)' and '#xpointer(id('ID'))' if the application also
intends to support any canonicalization that preserves comments.
(Otherwise URI="#foo" will automatically remove comments before the
canonicalization can even be invoked.) All other support for
XPointers is OPTIONAL, especially all support for barename and
other XPointers in external resources since the application may not
have control over how the fragment is generated (leading to
interoperability problems and validation failures).
The following examples demonstrate what the URI attribute
identifies and how it is dereferenced:
URI="http://example.com/bar.xml"- Identifies the octets that represent the external resource
'http//example.com/bar.xml', that is probably an XML document given
its file extension.
URI="http://example.com/bar.xml#chapter1"- Identifies the element with ID attribute value 'chapter1' of
the external XML resource 'http://example.com/bar.xml', provided as
an octet stream. Again, for the sake of interoperability, the
element identified as 'chapter1' should be obtained using an XPath
transform rather than a URI fragment (barename XPointer resolution
in external resources is not REQUIRED in this specification).
URI=""- Identifies the node-set (minus any comment nodes) of the XML
resource containing the signature
URI="#chapter1"- Identifies a node-set containing the element with ID attribute
value 'chapter1' of the XML resource containing the signature. XML
Signature (and its applications) modify this node-set to include
the element plus all descendents including namespaces and
attributes -- but not comments.
Dereferencing a same-document reference MUST result in an XPath
node-set suitable for use by Canonical XML. Specifically,
dereferencing a null URI (URI="") MUST result in an
XPath node-set that includes every non-comment node of the XML
document containing the URI attribute. In a fragment
URI, the characters after the number sign ('#') character conform
to the XPointer syntax [Xptr]. When
processing an XPointer, the application MUST behave as if the root
node of the XML document containing the URI attribute
were used to initialize the XPointer evaluation context. The
application MUST behave as if the result of XPointer processing
were a node-set derived from the resultant location-set as
follows:
- discard point nodes
- replace each range node with all XPath nodes having full or
partial content within the range
- replace the root node with its children (if it is in the
node-set)
- replace any element node E with E plus all
descendants of E (text, comment, PI, element) and all
namespace and attribute nodes of E and its descendant
elements.
- if the URI is not a full XPointer, then delete all comment
nodes
The second to last replacement is necessary because XPointer
typically indicates a subtree of an XML document's parse tree using
just the element node at the root of the subtree, whereas Canonical
XML treats a node-set as a set of nodes in which absence of
descendant nodes results in absence of their representative text
from the canonical form.
The last step is performed for null URIs, barename XPointers and
child sequence XPointers. It's necessary because when [XML-C14N] is passed a node-set, it
processes the node-set as is: with or without comments. Only when
it's called with an octet stream does it invoke it's own XPath
expressions (default or without comments). Therefore to retain the
default behavior of stripping comments when passed a node-set, they
are removed in the last step if the URI is not a full XPointer. To
retain comments while selecting an element by an identifier
ID, use the following full XPointer:
URI='#xpointer(id('ID'))'. To retain comments while
selecting the entire document, use the following full XPointer:
URI='#xpointer(/)'. This XPointer contains a simple
XPath expression that includes the root node, which the second to
last step above replaces with all nodes of the parse tree (all
descendants, plus all attributes, plus all namespaces nodes).
The optional Transforms element contains an ordered
list of Transform elements; these describe how the
signer obtained the data object that was digested. The output of
each Transform serves as input to the next
Transform. The input to the first
Transform is the result of dereferencing the
URI attribute of the Reference element.
The output from the last Transform is the input for
the DigestMethod algorithm. When transforms are
applied the signer is not signing the native (original) document
but the resulting (transformed) document. (See Only What is Signed is Secure (section
8.1).)
Each Transform consists of an
Algorithm attribute and content parameters, if any,
appropriate for the given algorithm. The Algorithm
attribute value specifies the name of the algorithm to be
performed, and the Transform content provides
additional data to govern the algorithm's processing of the
transform input. (Seee Algorithm Identifiers
and Implementation Requirements (section 6).)
As described in The
Reference Processing Model (section 4.3.3.2), some
transforms take an XPath node-set as input, while others require an
octet stream. If the actual input matches the input needs of the
transform, then the transform operates on the unaltered input. If
the transform input requirement differs from the format of the
actual input, then the input must be converted.
Some Transforms may require explicit MIME type,
charset (IANA registered "character set"), or other such
information concerning the data they are receiving from an earlier
Transform or the source data, although no
Transform algorithm specified in this document needs
such explicit information. Such data characteristics are provided
as parameters to the Transform algorithm and should be
described in the specification for the algorithm.
Examples of transforms include but are not limited to base64
decoding [MIME], canonicalization [XML-C14N], XPath filtering [XPath], and XSLT [XSLT]. The generic definition of the
Transform element also allows application-specific
transform algorithms. For example, the transform could be a
decompression routine given by a Java class appearing as a base64
encoded parameter to a Java Transform algorithm.
However, applications should refrain from using
application-specific transforms if they wish their signatures to be
verifiable outside of their application domain. Transform Algorithms (section 6.6)
defines the list of standard transformations.
Schema Definition:
<element name="Transforms" type="ds:TransformsType"/>
<complexType name="TransformsType">
<sequence>
<element ref="ds:Transform" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="Transform" type="ds:TransformType"/>
<complexType name="TransformType" mixed="true">
<choice minOccurs="0" maxOccurs="unbounded">
<any namespace="##other" processContents="lax"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
<element name="XPath" type="string"/>
</choice>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
DTD:
<!ELEMENT Transforms (Transform+)>
<!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* >
<!ATTLIST Transform
Algorithm CDATA #REQUIRED >
<!ELEMENT XPath (#PCDATA) >
DigestMethod is a required element that identifies
the digest algorithm to be applied to the signed object. This
element uses the general structure here for algorithms specified in
Algorithm Identifiers and Implementation
Requirements (section 6.1).
If the result of the URI dereference and application of
Transforms is an XPath node-set (or sufficiently functional
replacement implemented by the application) then it must be
converted as described in the Reference Processing
Model (section 4.3.3.2). If the result of URI dereference
and application of Transforms is an octet stream, then no
conversion occurs (comments might be present if the Canonical XML
with Comments was specified in the Transforms). The digest
algorithm is applied to the data octets of the resulting octet
stream.
Schema Definition:
<element name="DigestMethod" type="ds:DigestMethodType"/>
<complexType name="DigestMethodType" mixed="true">
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
DTD:
<!ELEMENT DigestMethod (#PCDATA %Method.ANY;)* >
<!ATTLIST DigestMethod
Algorithm CDATA #REQUIRED >
DigestValue is an element that contains the encoded value of the
digest. The digest is always encoded using base64 [MIME].
Schema Definition:
<element name="DigestValue" type="ds:DigestValueType"/>
<simpleType name="DigestValueType">
<restriction base="base64Binary"/>
</simpleType>
DTD:
<!ELEMENT DigestValue (#PCDATA) >
<!-- base64 encoded digest value -->
4.4 The KeyInfo Element
KeyInfo is an optional element that enables the
recipient(s) to obtain the key needed to validate the
signature. KeyInfo may contain keys, names,
certificates and other public key management information, such as
in-band key distribution or key agreement data. This specification
defines a few simple types but applications may extend those types
or all-together replace them with their own key identification and
exchange semantics using the XML namespace facility. [XML-ns] However, questions of trust of such
key information (e.g., its authenticity or strength) are out
of scope of this specification and left to the application.
If KeyInfo is omitted, the recipient is expected to
be able to identify the key based on application context. Multiple
declarations within KeyInfo refer to the same key.
While applications may define and use any mechanism they choose
through inclusion of elements from a different namespace, compliant
versions MUST implement KeyValue (section 4.4.2) and
SHOULD implement RetrievalMethod (section
4.4.3).
The schema/DTD specifications of many of KeyInfo's
children (e.g., PGPData, SPKIData,
X509Data) permit their content to be
extended/complemented with elements from another namespace. This
may be done only if it is safe to ignore these extension elements
while claiming support for the types defined in this specification.
Otherwise, external elements, including alternative
structures to those defined by this specification, MUST be a child
of KeyInfo. For example, should a complete XML-PGP
standard be defined, its root element MUST be a child of
KeyInfo. (Of course, new structures from external
namespaces can incorporate elements from the
&dsig; namespace via features of the type
definition language. For instance, they can create a DTD that mixes
their own and dsig qualified elements, or a schema that permits,
includes, imports, or derives new types based on
&dsig; elements.)
The following list summarizes the KeyInfo types
that are allocated an identifier in the &dsig;
namespace; these can be used within the
RetrievalMethod Type attribute to
describe a remote KeyInfo structure.
In addition to the types above for which we define an XML
structure, we specify one additional type to indicate a binary (ASN.1
DER) X.509 Certificate.
Schema Definition:
<element name="KeyInfo" type="ds:KeyInfoType"/>
<complexType name="KeyInfoType" mixed="true">
<choice maxOccurs="unbounded">
<element ref="ds:KeyName"/>
<element ref="ds:KeyValue"/>
<element ref="ds:RetrievalMethod"/>
<element ref="ds:X509Data"/>
<element ref="ds:PGPData"/>
<element ref="ds:SPKIData"/>
<element ref="ds:MgmtData"/>
<any processContents="lax" namespace="##other"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
DTD:
<!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* >
<!ATTLIST KeyInfo
Id ID #IMPLIED >
4.4.1 The KeyName Element
The KeyName element contains a string value (in
which white space is significant) which may be used by the signer
to communicate a key identifier to the recipient. Typically,
KeyName contains an identifier related to the key pair
used to sign the message, but it may contain other protocol-related
information that indirectly identifies a key pair. (Common uses of
KeyName include simple string names for keys, a key
index, a distinguished name (DN), an email address, etc.)
Schema Definition:
<element name="KeyName" type="string"/>
DTD:
<!ELEMENT KeyName (#PCDATA) >
4.4.2 The KeyValue Element
The KeyValue element contains a single public key
that may be useful in validating the signature. Structured formats
for defining DSA (REQUIRED) and RSA (RECOMMENDED) public keys are
defined in Signature Algorithms
(section 6.4). The KeyValue element may include
externally defined public keys values represented as PCDATA or
element types from an external namespace.
Schema Definition:
<element name="KeyValue" type="ds:KeyValueType"/>
<complexType name="KeyValueType" mixed="true">
<choice>
<element ref="ds:DSAKeyValue"/>
<element ref="ds:RSAKeyValue"/>
<any namespace="##other" processContents="lax"/>
</choice>
</complexType>
DTD:
<!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY;)* >
- Identifier
Type="http//www.w3.org/2000/09/xmldsig#DSAKeyValue"
(this can be used within a RetrievalMethod or
Reference element to identify the referent's
type)
DSA keys and the DSA signature algorithm are specified in [DSS].
DSA public key values can have the following fields:
P- a prime modulus meeting the [DSS] requirements
Q- an integer in the range 2**159 < Q < 2**160 which is a
prime divisor of P-1
G- an integer with certain properties with respect to P and Q
J- (P - 1) / Q
Y- G**X mod P (where X is part of the private key and not made
public)
seed- a DSA prime generation seed
pgenCounter- a DSA prime generation counter
Parameter J is avilable for inclusion solely for efficiency as
it is calculatable from P and Q. Parameters seed and pgenCounter
are used in the DSA prime number generation algorithm specified in
[DSS]. As such, they are optional but must either both be present
or both be absent. This prime generation algorithm is designed to
provide assurance that a weak prime is not being used and it yields
a P and Q value. Parameters P, Q, and G can be public and common to
a group of users. They might be known from application context. As
such, they are optional but P and Q must either both appear or both
be absent. If all of P, Q,
seed, and pgenCounter are present,
implementations are not required to check if they are consistent
and are free to use either P and Q or
seed and pgenCounter. All parameters are
encoded as base64 [MIME] values.
Arbitrary-length integers (e.g. "bignums" such as RSA moduli)
are represented in XML as octet strings as defined by the ds:CryptoBinary type.
Schema:
<element name="DSAKeyValue" type="ds:DSAKeyValueType"/>
<complexType name="DSAKeyValueType">
<sequence>
<sequence minOccurs="0">
<element name="P" type="ds:CryptoBinary"/>
<element name="Q" type="ds:CryptoBinary"/>
</sequence>
<element name="J" type="ds:CryptoBinary" minOccurs="0"/>
<element name="G" type="ds:CryptoBinary" minOccurs="0"/>
<element name="Y" type="ds:CryptoBinary"/>
<sequence minOccurs="0">
<element name="Seed" type="ds:CryptoBinary"/>
<element name="PgenCounter" type="ds:CryptoBinary"/>
</sequence>
</sequence>
</complexType>
DTD:
<!ELEMENT DSAKeyValue (P, Q)?, J?, G?, Y, (Seed, PgenCounter)?) >
<!ELEMENT P (#PCDATA) >
<!ELEMENT Q (#PCDATA) >
<!ELEMENT J (#PCDATA) >
<!ELEMENT G (#PCDATA) >
<!ELEMENT Y (#PCDATA) >
<!ELEMENT Seed (#PCDATA) >
<!ELEMENT PgenCounter (#PCDATA) >
- Identifier
Type="http//www.w3.org/2000/09/xmldsig#RSAKeyValue"
(this can be used within a RetrievalMethod or
Reference element to identify the referent's
type)
RSA key values have two fields: Modulus and Exponent.
<RSAKeyValue>
<Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
Arbitrary-length integers (e.g. "bignums" such as RSA moduli)
are represented in XML as octet strings as defined by the ds:CryptoBinary type.
Schema:
<element name="RSAKeyValue" type="ds:RSAKeyValueType"/>
<complexType name="RSAKeyValueType">
<sequence>
<element name="Modulus" type="ds:CryptoBinary"/>
<element name="Exponent" type="ds:CryptoBinary"/>
</sequence>
</complexType>
DTD:
<!ELEMENT RSAKeyValue (Modulus, Exponent) >
<!ELEMENT Modulus (#PCDATA) >
<!ELEMENT Exponent (#PCDATA) >
A RetrievalMethod element within
KeyInfo is used to convey a reference to
KeyInfo information that is stored at another
location. For example, several signatures in a document might use a
key verified by an X.509v3 certificate chain appearing once in the
document or remotely outside the document; each signature's
KeyInfo can reference this chain using a single
RetrievalMethod element instead of including the
entire chain with a sequence of X509Certificate
elements.
RetrievalMethod uses the same syntax and
dereferencing behavior as Reference's URI (section 4.3.3.1)
and The Reference
Processing Model (section 4.3.3.2) except that there is no
DigestMethod or DigestValue child
elements and presence of the URI is mandatory.
Type is an optional identifier for the type of data
to be retrieved. The result of dereferencing a
RetrievalMethod Reference for all KeyInfo types defined by this
specification (section 4.4) with a corresponding XML structure
is an XML element or document with that element as the root. The
rawX509Certificate KeyInfo (for which
there is no XML structure) returns a binary X509 certificate.
Schema Definition
<element name="RetrievalMethod" type="ds:RetrievalMethodType"/>
<complexType name="RetrievalMethodType">
<sequence>
<element name="Transforms" type="ds:TransformsType" minOccurs="0"/>
</sequence>
<attribute name="URI" type="anyURI"/>
<attribute name="Type" type="anyURI" use="optional"/>
</complexType>
DTD
<!ELEMENT RetrievalMethod (Transforms?) >
<!ATTLIST RetrievalMethod
URI CDATA #REQUIRED
Type CDATA #IMPLIED >
4.4.4 The X509Data Element
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#X509Data
"
(this can be used within a RetrievalMethod or
Reference element to identify the referent's
type)
An X509Data element within KeyInfo
contains one or more identifiers of keys or X509 certificates (or
certificates' identifiers or a revocation list). The content of
X509Data is:
- At least one element, from the following set of element types;
any of these may appear together or more than once iff (if and only
if) each instance describes the same certificate:
-
- The
X509IssuerSerial element, which contains an
X.509 issuer distinguished name/serial number pair that SHOULD be
compliant with RFC2253 [LDAP-DN],
- The
X509SubjectName element, which contains an
X.509 subject distinguished name that SHOULD be compliant with
RFC2253 [LDAP-DN],
- The
X509SKI element, which contains the base64
encoded plain (i.e. non-DER-encoded) value of a X509 V.3
SubjectKeyIdentifier extension.
- The
X509Certificate element, which contains a
base64-encoded [X509v3] certificate,
and
- Elements from an external namespace which
accompanies/complements any of the elements above.
- The
X509CRL element, which contains a
base64-encoded certificate revocation list (CRL) [X509v3].
Any X509IssuerSerial, X509SKI, and
X509SubjectName elements that appear MUST refer to the
certificate or certificates containing the validation key. All such
elements that refer to a particular individual certificate MUST be
grouped inside a single X509Data element and if the
certificate to which they refer appears, it MUST also be in that
X509Data element.
Any X509IssuerSerial, X509SKI, and
X509SubjectName elements that relate to the same key
but different certificates MUST be grouped within a single
KeyInfo but MAY occur in multiple
X509Data elements.
All certificates appearing in an X509Data element
MUST relate to the validation key by either containing it or being
part of a certification chain that terminates in a certificate
containing the validation key.
No ordering is implied by the above constraints. The comments in
the following instance demonstrate these constraints:
<KeyInfo>
<X509Data> <!-- two pointers to certificate-A -->
<X509IssuerSerial>
<X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
<X509SerialNumber>12345678</X509SerialNumber>
</X509IssuerSerial>
<X509SKI>31d97bd7</X509SKI>
</X509Data>
<X509Data><!-- single pointer to certificate-B -->
<X509SubjectName>Subject of Certificate B</X509SubjectName>
</X509Data>
<X509Data> <!-- certificate chain -->
<!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
<X509Certificate>MIICXTCCA..</X509Certificate>
<!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US
issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<X509Certificate>MIICPzCCA...</X509Certificate>
<!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<X509Certificate>MIICSTCCA...</X509Certificate>
</X509Data>
</KeyInfo>
Note, there is no direct provision for a PKCS#7 encoded "bag" of
certificates or CRLs. However, a set of certificates and CRLs can
occur within an X509Data element and multiple
X509Data elements can occur in a KeyInfo.
Whenever multiple certificates occur in an X509Data
element, at least one such certificate must contain the public key
which verifies the signature.
Also, strings in DNames
(X509IssuerSerial,X509SubjectName, and
KeyNameif approriate) should be encoded as
follows:
- Consider the string as consisting of unicode characters.
- Escape occurences of the following special characters by
prefixing it with the "\" character:
- a "#" character occurring at the beginning of the string
- one of the characters ",", "+", """, "\", "<", ">" or
";"
- Escape all occurences of ASCII control characters (Unicode
range \x00 - \x20) by replacing them with "\" followed by a two
digit hex number showing its Unicode number. Since a XML document
logically consists of characters, not octets, the resulting unicode
string is finally encoded according to the character encoding used
for producing the physical representation of the XML document.
Schema Definition
<element name="X509Data" type="ds:X509DataType"/>
<complexType name="X509DataType">
<sequence maxOccurs="unbounded">
<choice>
<element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/>
<element name="X509SKI" type="base64Binary"/>
<element name="X509SubjectName" type="string"/>
<element name="X509Certificate" type="base64Binary"/>
<element name="X509CRL" type="base64Binary"/>
<any namespace="##other" processContents="lax"/>
</choice>
</sequence>
</complexType>
<complexType name="X509IssuerSerialType">
<sequence>
<element name="X509IssuerName" type="string"/>
<element name="X509SerialNumber" type="integer"/>
</sequence>
</complexType>
DTD
<!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
X509Certificate)+ | X509CRL %X509.ANY;)>
<!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
<!ELEMENT X509IssuerName (#PCDATA) >
<!ELEMENT X509SubjectName (#PCDATA) >
<!ELEMENT X509SerialNumber (#PCDATA) >
<!ELEMENT X509SKI (#PCDATA) >
<!ELEMENT X509Certificate (#PCDATA) >
<!ELEMENT X509CRL (#PCDATA) >
<!-- Note, this DTD and schema permits X509Data to be empty; this is
precluded by the text in KeyInfo Element (section 4.4) which states
that at least one element from the dsig namespace should be present
in the PGP, SPKI, and X509 structures. This is easily expressed for
the other key types, but not for X509Data because of its rich
structure. -->
4.4.5 The PGPData Element
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#PGPData
"
(this can be used within a RetrievalMethod or
Reference element to identify the referent's
type)
The PGPData element within KeyInfo is
used to convey information related to PGP public key pairs and
signatures on such keys. The PGPKeyID's value is a
base64Binary sequence containing a standard PGP public key
identifier as defined in [PGP, section
11.2]. The PGPKeyPacket contains a base64-encoded Key
Material Packet as defined in [PGP, section
5.5]. These children element types can be complemented/extended by
siblings from an external namespace within PGPData, or
PGPData can be replaced all-together with an
alternative PGP XML structure as a child of KeyInfo.
PGPData must contain one PGPKeyID and/or
one PGPKeyPacket and 0 or more elements from an
external namespace.
Schema Definition:
<element name="PGPData" type="ds:PGPDataType"/>
<complexType name="PGPDataType">
<choice>
<sequence>
<element name="PGPKeyID" type="base64Binary"/>
<element name="PGPKeyPacket" type="base64Binary" minOccurs="0"/>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<sequence>
<element name="PGPKeyPacket" type="base64Binary"/>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</choice>
</complexType>
DTD:
<!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket) %PGPData.ANY;) >
<!ELEMENT PGPKeyPacket (#PCDATA) >
<!ELEMENT PGPKeyID (#PCDATA) >
4.4.6 The SPKIData Element
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#SPKIData
"
(this can be used within a RetrievalMethod or
Reference element to identify the referent's
type)
The SPKIData element within KeyInfo is
used to convey information related to SPKI public key pairs,
certificates and other SPKI data. SPKISexp is the
base64 encoding of a SPKI canonical S-expression.
SPKIData must have at least one SPKISexp;
SPKISexp can be complemented/extended by siblings from
an external namespace within SPKIData, or
SPKIData can be entirely replaced with an alternative
SPKI XML structure as a child of KeyInfo.
Schema Definition:
<element name="SPKIData" type="ds:SPKIDataType"/>
<complexType name="SPKIDataType">
<sequence maxOccurs="unbounded">
<element name="SPKISexp" type="base64Binary"/>
<any namespace="##other" processContents="lax" minOccurs="0"/>
</sequence>
</complexType>
DTD:
<!ELEMENT SPKIData (SPKISexp %SPKIData.ANY;) >
<!ELEMENT SPKISexp (#PCDATA) >
4.4.7 The MgmtData Element
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#MgmtData
"
(this can be used within a RetrievalMethod or
Reference element to identify the referent's
type)
The MgmtData element within KeyInfo is
a string value used to convey in-band key distribution or agreement
data. For example, DH key exchange, RSA key encryption, etc. Use of
this elemet is NOT RECOMMENDED. It provides a syntactic hook where
in-band key distribution or agreement data can be placed. However,
superior interoperable child elements of KeyInfo for
the transmission of encrypted keys and for key agreement are being
specified by the W3C XML Encryption Working Group and they should
be used instead of MgmtData.
Schema Definition:
<element name="MgmtData" type="string"/>
DTD:
<!ELEMENT MgmtData (#PCDATA)>
4.5 The Object Element
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#Object"
(this can be used within a Reference element
to identify the referent's type)
Object is an optional element that may occur one or
more times. When present, this element may contain any data. The
Object element may include optional MIME type, ID, and
encoding attributes.
The Object's Encoding attributed may
be used to provide a URI that identifies the method by which the
object is encoded (e.g., a binary file).
The MimeType attribute is an optional attribute
which describes the data within the Object
(independent of its encoding). This is a string with values defined
by [MIME]. For example, if the
Object contains base64 encoded PNG, the
Encoding may be specified as 'base64' and the
MimeType as 'image/png'. This attribute is purely
advisory; no validation of the MimeType information is
required by this specification. Applications which require
normatiave type and encoding information for signature validation
should specify Transforms with well defined
resulting types and/or encodings.
The Object's Id is commonly referenced
from a Reference in SignedInfo, or
Manifest. This element is typically used for enveloping
signatures where the object being signed is to be included in
the signature element. The digest is calculated over the entire
Object element including start and end tags.
Note, if the application wishes to exclude the
<Object> tags from the digest calculation the
Reference must identify the actual data object (easy
for XML documents) or a transform must be used to remove the
Object tags (likely where the data object is non-XML).
Exclusion of the object tags may be desired for cases where one
wants the signature to remain valid if the data object is moved
from inside a signature to outside the signature (or vice versa),
or where the content of the Object is an encoding of
an original binary document and it is desired to extract and decode
so as to sign the original bitwise representation.
Schema Definition:
<element name="Object" type="ds:ObjectType"/>
<complexType name="ObjectType" mixed="true">
<sequence minOccurs="0" maxOccurs="unbounded">
<any namespace="##any" processContents="lax"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
<attribute name="MimeType" type="string" use="optional"/>
<attribute name="Encoding" type="anyURI" use="optional"/>
</complexType>
DTD:
<!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest %Object.ANY;)* >
<!ATTLIST Object
Id ID #IMPLIED
MimeType CDATA #IMPLIED
Encoding CDATA #IMPLIED >
This section describes the optional to implement
Manifest and SignatureProperties elements
and describes the handling of XML processing instructions and
comments. With respect to the elements Manifest and
SignatureProperties this section specifies syntax and
little behavior -- it is left to the application. These elements
can appear anywhere the parent's content model permits; the
Signature content model only permits them within
Object.
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#Manifest"
(this can be used within a Reference element
to identify the referent's type)
The Manifest element provides a list of
References. The difference from the list in
SignedInfo is that it is application defined which, if
any, of the digests are actually checked against the objects
referenced and what to do if the object is inaccessible or the
digest compare fails. If a Manifest is pointed to from
SignedInfo, the digest over the Manifest
itself will be checked by the core signature validation behavior.
The digests within such a Manifest are checked at the
application's discretion. If a Manifest is referenced
from another Manifest, even the overall digest of this
two level deep Manifest might not be checked.
Schema Definition:
<element name="Manifest" type="ds:ManifestType"/>
<complexType name="ManifestType">
<sequence>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
DTD:
<!ELEMENT Manifest (Reference+) >
<!ATTLIST Manifest
Id ID #IMPLIED >
-
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"
(this can be used within a Reference element
to identify the referent's type)
Additional information items concerning the generation of the
signature(s) can be placed in a SignatureProperty
element (i.e., date/time stamp or the serial number of
cryptographic hardware used in signature generation).
Schema Definition:
<element name="SignatureProperties" type="ds:SignaturePropertiesType"/>
<complexType name="SignaturePropertiesType">
<sequence>
<element ref="ds:SignatureProperty" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
<element name="SignatureProperty" type="ds:SignaturePropertyType"/>
<complexType name="SignaturePropertyType" mixed="true">
<choice maxOccurs="unbounded">
<any namespace="##other" processContents="lax"/>
<!-- (1,1) elements from (1,unbounded) namespaces -->
</choice>
<attribute name="Target" type="anyURI" use="required"/>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
DTD:
<!ELEMENT SignatureProperties (SignatureProperty+) >
<!ATTLIST SignatureProperties
Id ID #IMPLIED >
<!ELEMENT SignatureProperty (#PCDATA %SignatureProperty.ANY;)* >
<!ATTLIST SignatureProperty
Target CDATA #REQUIRED
Id ID #IMPLIED >
No XML processing instructions (PIs) are used by this
specification.
Note that PIs placed inside SignedInfo by an
application will be signed unless the
CanonicalizationMethod algorithm discards them. (This
is true for any signed XML content.) All of the
CanonicalizationMethods identified within this
specification retain PIs. When a PI is part of content that is
signed (e.g., within SignedInfo or referenced XML
documents) any change to the PI will obviously result in a
signature failure.
5.4 in
Signature Elements
XML comments are not used by this specification.
Note that unless CanonicalizationMethod removes
comments within SignedInfo or any other referenced XML
(which [XML-C14N] does), they will be
signed. Consequently, if they are retained, a change to the comment
will cause a signature failure. Similarly, the XML signature over
any XML data will be sensitive to comment changes unless a
comment-ignoring canonicalization/transform method, such as the
Canonical XML [XML-C14N], is
specified.
This section identifies algorithms used with the XML digital
signature specification. Entries contain the identifier to be used
in Signature elements, a reference to the formal
specification, and definitions, where applicable, for the
representation of keys and the results of cryptographic
operations.
6.1 Algorithm
Identifiers and Implementation Requirements
Algorithms are identified by URIs that appear as an attribute to
the element that identifies the algorithms' role
(DigestMethod, Transform,
SignatureMethod, or
CanonicalizationMethod). All algorithms used herein
take parameters but in many cases the parameters are implicit. For
example, a SignatureMethod is implicitly given two
parameters: the keying info and the output of
CanonicalizationMethod. Explicit additional parameters
to an algorithm appear as content elements within the algorithm
role element. Such parameter elements have a descriptive element
name, which is frequently algorithm specific, and MUST be in the
XML Signature namespace or an algorithm specific namespace.
This specification defines a set of algorithms, their URIs, and
requirements for implementation. Requirements are specified over
implementation, not over requirements for signature use.
Furthermore, the mechanism is extensible; alternative algorithms
may be used by signature applications.
- Digest
-
- Required SHA1
http://www.w3.org/2000/09/xmldsig#sha1
- Encoding
-
- Required base64
http://www.w3.org/2000/09/xmldsig#base64
- MAC
-
- Required HMAC-SHA1
http://www.w3.org/2000/09/xmldsig#hmac-sha1
- Signature
-
- Required DSAwithSHA1 (DSS)
http://www.w3.org/2000/09/xmldsig#dsa-sha1
- Recommended RSAwithSHA1
http://www.w3.org/2000/09/xmldsig#rsa-sha1
- Canonicalization
-
- Required Canonical XML (omits comments)
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
- Recommended Canonical XML with Comments
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
- Transform
-
- Optional XSLT
http://www.w3.org/TR/1999/REC-xslt-19991116
- Recommended XPath
http://www.w3.org/TR/1999/REC-xpath-19991116
- Required Enveloped Signature*
http://www.w3.org/2000/09/xmldsig#enveloped-signature
* The Enveloped Signature transform removes the
Signature element from the calculation of the
signature when the signature is within the content that it is being
signed. This MAY be implemented via the RECOMMENDED XPath
specification specified in 6.6.4: Enveloped Signature Transform;
it MUST have the same effect as that specified by the XPath Transform.
Only one digest algorithm is defined herein. However, it is
expected that one or more additional strong digest algorithms will
be developed in connection with the US Advanced Encryption Standard
effort. Use of MD5 [MD5] is NOT RECOMMENDED because recent advances
in cryptanalysis have cast doubt on its strength.
- Identifier:
- http://www.w3.org/2000/09/xmldsig#sha1
The
SHA-1 algorithm [SHA-1] takes no
explicit parameters. An example of an SHA-1 DigestAlg element
is:
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
A SHA-1 digest is a 160-bit string. The content of the
DigestValue element shall be the base64 encoding of this bit string
viewed as a 20-octet octet stream. For example, the DigestValue
element for the message digest:
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be:
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
MAC algorithms take two implicit parameters, their keying
material determined from KeyInfo and the octet stream
output by CanonicalizationMethod. MACs and signature
algorithms are syntactically identical but a MAC implies a shared
secret key.
- Identifier:
- http://www.w3.org/2000/09/xmldsig#hmac-sha1
The HMAC
algorithm (RFC2104 [HMAC]) takes the
truncation length in bits as a parameter; if the parameter is not
specified then all the bits of the hash are output. An example of
an HMAC SignatureMethod element:
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<HMACOutputLength>128</HMACOutputLength>
</SignatureMethod>
The output of the HMAC algorithm is ultimately the output
(possibly truncated) of the chosen digest algorithm. This value
shall be base64 encoded in the same straightforward fashion as the
output of the digest algorithms. Example: the SignatureValue
element for the HMAC-SHA1 digest
9294727A 3638BB1C 13F48EF8 158BFC9D
from the test vectors in [HMAC] would
be
<SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>
Schema Definition:
<simpleType name="HMACOutputLengthType">
<restriction base="integer"/>
</simpleType>
DTD:
<!ELEMENT HMACOutputLength (#PCDATA)>
Signature algorithms take two implicit parameters, their keying
material determined from KeyInfo and the octet stream
output by CanonicalizationMethod. Signature and MAC
algorithms are syntactically identical but a signature implies
public key cryptography.
- Identifier:
- http://www.w3.org/2000/09/xmldsig#dsa-sha1
The DSA algorithm [DSS] takes no explicit
parameters. An example of a DSA SignatureMethod
element is:
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
The output of the DSA algorithm consists of a pair of integers
usually referred by the pair (r, s). The signature value consists
of the base64 encoding of the concatenation of two octet-streams
that respectively result from the octet-encoding of the values r
and s in that order. Integer to octet-stream conversion must be
done according to the I2OSP operation defined in the RFC 2437 [PKCS1] specification with a l
parameter equal to 20. For example, the SignatureValue element for
a DSA signature (r, s) with values
specified in hexadecimal:
r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0
s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
from the example in Appendix 5 of the DSS standard would be
<SignatureValue>
i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==</SignatureValue>
6.4.2 PKCS1
(RSA-SHA1)
- Identifier:
- http://www.w3.org/2000/09/xmldsig#rsa-sha1
The expression "RSA algorithm" as used in this draft refers to
the RSASSA-PKCS1-v1_5 algorithm described in RFC 2437 [PKCS1]. The RSA algorithm takes no explicit
parameters. An example of an RSA SignatureMethod element is:
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
The SignatureValue content for an RSA signature is
the base64 [MIME] encoding of the octet
string computed as per RFC 2437 [PKCS1, section 8.1.1: Signature generation
for the RSASSA-PKCS1-v1_5 signature scheme]. As specified in the
EMSA-PKCS1-V1_5-ENCODE function RFC 2437 [PKCS1, section 9.2.1], the value input to the
signature function MUST contain a pre-pended algorithm object
identifier for the hash function, but the availability of an ASN.1
parser and recognition of OIDs is not required of a signature
verifier. The PKCS#1 v1.5 representation appears as:
CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
Note that the padded ASN.1 will be of the following form:
01 | FF* | 00 | prefix | hash
where "|" is concatentation, "01", "FF", and "00" are fixed
octets of the corresponding hexadecimal value, "hash" is the SHA1
digest of the data, and "prefix" is the ASN.1 BER SHA1 algorithm
designator prefix required in PKCS1 [RFC 2437], that is,
hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
This prefix is included to make it easier to use standard
cryptographic libraries. The FF octet MUST be repeated the maximum
number of times such that the value of the quantity being CRYPTed
is one octet shorter than the RSA modulus.
The resulting base64 [MIME] string is
the value of the child text node of the SignatureValue element,
e.g.
<SignatureValue>
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
</SignatureValue>
If canonicalization is performed over octets, the
canonicalization algorithms take two implicit parameters: the
content and its charset. The charset is derived according to the
rules of the transport protocols and media types (e.g, RFC2376 [XML-MT] defines the media types for XML).
This information is necessary to correctly sign and verify
documents and often requires careful server side configuration.
Various canonicalization algorithms require conversion to [UTF-8].The two algorithms below understand at
least [UTF-8] and [UTF-16] as input encodings. We RECOMMEND
that externally specified algorithms do the same. Knowledge of
other encodings is OPTIONAL.
Various canonicalization algorithms transcode from a non-Unicode
encoding to Unicode. The two algorithms below perform text
normalization during transcoding [NFC, NFC-Corrigendum]. We RECOMMEND that
externally specified canonicalization algorithms do the same.
(Note, there can be ambiguities in converting existing charsets to
Unicode, for an example see the XML Japanese Profile [XML-Japanese] NOTE.)
- Identifier for REQUIRED Canonical XML (omits comments):
- http://www.w3.org/TR/2001/REC-xml-c14n-20010315
- Identifier for Canonical XML with Comments:
-
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
An example of an XML canonicalization element is:
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
The normative specification of Canonical XML is [XML-C14N]. The algorithm is capable of
taking as input either an octet stream or an XPath node-set (or
sufficiently functional alternative). The algorithm produces an
octet stream as output. Canonical XML is easily parameterized (via
an additional URI) to omit or retain comments.
A Transform algorithm has a single implicit
parameter: an octet stream from the Reference or the
output of an earlier Transform.
Application developers are strongly encouraged to support all
transforms listed in this section as RECOMMENDED unless the
application environment has resource constraints that would make
such support impractical. Compliance with this recommendation will
maximize application interoperability and libraries should be
available to enable support of these transforms in applications
without extensive development.
Any canonicalization algorithm that can be used for
CanonicalizationMethod (such as those in Canonicalization Algorithms (section 6.5))
can be used as a Transform.
- Identifiers:
- http://www.w3.org/2000/09/xmldsig#base64
The normative specification for base64 decoding transforms is
[MIME]. The base64 Transform
element has no content. The input is decoded by the algorithms.
This transform is useful if an application needs to sign the raw
data associated with the encoded content of an element.
This transform requires an octet stream for input. If an XPath
node-set (or sufficiently functional alternative) is given as
input, then it is converted to an octet stream by performing
operations logically equivalent to 1) applying an XPath transform
with expression self::text(), then 2) taking the
string-value of the node-set. Thus, if an XML element is identified
by a barename XPointer in the Reference URI, and its
content consists solely of base64 encoded character data, then this
transform automatically strips away the start and end tags of the
identified element and any of its descendant elements as well as
any descendant comments and processing instructions. The output of
this transform is an octet stream.
6.6.3 XPath
Filtering
- Identifier:
- http://www.w3.org/TR/1999/REC-xpath-19991116
The normative specification for XPath expression evaluation is
[XPath].
The XPath expression to be evaluated appears as the character
content of a transform parameter child element named
XPath.
The input required by this transform is an XPath node-set. Note
that if the actual input is an XPath node-set resulting from a null
URI or barename XPointer dereference, then comment nodes will have
been omitted. If the actual input is an octet stream, then the
application MUST convert the octet stream to an XPath node-set
suitable for use by Canonical XML with Comments. (A subsequent
application of the REQUIRED Canonical XML algorithm would strip
away these comments.) In other words, the input node-set should be
equivalent to the one that would be created by the following
process:
- Initialize an XPath evaluation context by setting the initial
node equal to the input XML document's root node, and set the
context position and size to 1.
- Evaluate the XPath expression
(//. | //@* |
//namespace::*)
The evaluation of this expression includes all of the document's
nodes (including comments) in the node-set representing the octet
stream.
The transform output is also an XPath node-set. The XPath
expression appearing in the XPath parameter is
evaluated once for each node in the input node-set. The result is
converted to a boolean. If the boolean is true, then the node is
included in the output node-set. If the boolean is false, then the
node is omitted from the output node-set.
Note: Even if the input node-set has had comments
removed, the comment nodes still exist in the underlying parse tree
and can separate text nodes. For example, the markup
<e>Hello, <!-- comment -->world!</e>
contains two text nodes. Therefore, the expression
self::text()[string()="Hello, world!"] would fail.
Should this problem arise in the application, it can be solved by
either canonicalizing the document before the XPath transform to
physically remove the comments or by matching the node based on the
parent element's string value (e.g. by using the expression
self::text()[string(parent::e)="Hello, world!"]).
The primary purpose of this transform is to ensure that only
specifically defined changes to the input XML document are
permitted after the signature is affixed. This is done by omitting
precisely those nodes that are allowed to change once the signature
is affixed, and including all other input nodes in the output. It
is the responsibility of the XPath expression author to include all
nodes whose change could affect the interpretation of the transform
output in the application context.
An important scenario would be a document requiring two
enveloped signatures. Each signature must omit itself from its own
digest calculations, but it is also necessary to exclude the second
signature element from the digest calculations of the first
signature so that adding the second signature does not break the
first signature.
The XPath transform establishes the following evaluation context
for each node of the input node-set:
- A context node equal to a node of the input
node-set.
- A context position, initialized to 1.
- A context size, initialized to 1.
- A library of functions equal to the function set defined
in XPath
plus a function named here.
- A set of variable bindings. No means for initializing these is
defined. Thus, the set of variable bindings used when evaluating
the XPath expression is empty, and use of a variable reference in
the XPath expression results in an error.
- The set of namespace declarations in scope for the XPath
expression.
As a result of the context node setting, the XPath expressions
appearing in this transform will be quite similar to those used in
used in [XSLT], except that the size and
position are always 1 to reflect the fact that the transform is
automatically visiting every node (in XSLT, one recursively calls
the command apply-templates to visit the nodes of the
input tree).
The function here() is defined as
follows:
Function:
node-set here()
The here function returns a
node-set containing the attribute or processing instruction node or
the parent element of the text node that directly bears the XPath
expression. This expression results in an error if the
containing XPath expression does not appear in the same XML
document against which the XPath expression is being evaluated.
As an example, consider creating an enveloped signature (a
Signature element that is a descendant of an element
being signed). Although the signed content should not be changed
after signing, the elements within the Signature
element are changing (e.g. the digest value must be put inside the
DigestValue and the SignatureValue must
be subsequently calculated). One way to prevent these changes from
invalidating the digest value in DigestValue is to add
an XPath Transform that omits all
Signature elements and their descendants. For
example,
<Document>
...
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<XPath xmlns:dsig="&dsig;">
not(ancestor-or-self::dsig:Signature)
</XPath>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue></DigestValue>
</Reference>
</SignedInfo>
<SignatureValue></SignatureValue>
</Signature>
...
</Document>
Due to the null Reference URI in this example, the
XPath transform input node-set contains all nodes in the entire
parse tree starting at the root node (except the comment nodes).
For each node in this node-set, the node is included in the output
node-set except if the node or one of its ancestors has a tag of
Signature that is in the namespace given by the
replacement text for the entity &dsig;.
A more elegant solution uses the here function to omit only the
Signature containing the XPath Transform, thus
allowing enveloped signatures to sign other signatures. In the
example above, use the XPath element:
<XPath xmlns:dsig="&dsig;">
count(ancestor-or-self::dsig:Signature |
here()/ancestor::dsig:Signature[1]) >
count(ancestor-or-self::dsig:Signature)</XPath>
Since the XPath equality operator converts node sets to string
values before comparison, we must instead use the XPath union
operator (|). For each node of the document, the predicate
expression is true if and only if the node-set containing the node
and its Signature element ancestors does not include
the enveloped Signature element containing the XPath
expression (the union does not produce a larger set if the
enveloped Signature element is in the node-set given
by ancestor-or-self::Signature).
- Identifier:
- http://www.w3.org/2000/09/xmldsig#enveloped-signature
An enveloped signature transform T removes the
whole Signature element containing T
from the digest calculation of the Reference element
containing T. The entire string of characters used by
an XML processor to match the Signature with the XML
production element is removed. The output of the
transform is equivalent to the output that would result from
replacing T with an XPath transform containing the
following XPath parameter element:
<XPath xmlns:dsig="&dsig;">
count(ancestor-or-self::dsig:Signature |
here()/ancestor::dsig:Signature[1]) >
count(ancestor-or-self::dsig:Signature)</XPath>
The input and output requirements of this transform are
identical to those of the XPath transform. Note that it is not
necessary to use an XPath expression evaluator to create this
transform. However, this transform MUST produce output in exactly
the same manner as the XPath transform parameterized by the XPath
expression above.
6.6.5 XSLT Transform
- Identifier:
- http://www.w3.org/TR/1999/REC-xslt-19991116
The normative specification for XSL Transformations is [XSLT].
Specification of a namespace-qualified stylesheet element, which
MUST be the sole child of the Transform element,
indicates that the specified style sheet should be used. Whether
this instantiates in-line processing of local XSLT declarations
within the resource is determined by the XSLT processing model; the
ordered application of multiple stylesheet may require multiple
Transforms. No special provision is made for the
identification of a remote stylesheet at a given URI because it can
be communicated via an
xsl:include or
xsl:import within the stylesheet
child of the Transform.
This transform requires an octet stream as input. If the actual
input is an XPath node-set, then the signature application should
attempt to convert it to octets (apply Canonical XML]) as described in the Reference Processing
Model (section 4.3.3.2).
The output of this transform is an octet stream. The processing
rules for the XSL style sheet or transform element are stated in
the XSLT specification [XSLT]. We
RECOMMEND that XSLT transform authors use an output method of
xml for XML and HTML. As XSLT implementations do not
produce consistent serializations of their output, we further
RECOMMEND inserting a transform after the XSLT transform to
canonicalize the output. These steps will help to ensure
interoperability of the resulting signatures among applications
that support the XSLT transform. Note that if the output is
actually HTML, then the result of these steps is logically
equivalent [XHTML].
- Identifier:
- http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
The normative specification for XML Schema is [XML-Schema]. Use of the schema
validation transform without any parameters indicates that the
document should be processed according to information within the
resource being transformed. Use of a name-space qualified
schema element, which must be the sole child of the
Transform, indicates the specified schema should be
used for validation; whether this instantiates other validation
using other schema is determined by the XML Schema processing
model; the ordered application of multiple schema validations may
require multiple Transforms. No special provision is
made for the identification of a remote stylesheet at a given URI
because it can be communicated via an
xsd:include or
xsd:import within the schema child of
the Transform.
This transform requires a specified set of "Required
Information Set Items and Properties" [XML-schema, Appendix D]. If the input is
octets, the octets must be parsed. If the input is an XPath
node-set, this node-set may be able to serve as the necessary
information set. Note, while the changes made to an information set
by schema validation are largely augmentations, and consequently
not contained in the XPath data model, schema validation can affect
default attribute and element content values. Consequently, the
presense and order of schema validation may affect the canonical
form.
7.0 XML Canonicalization and Syntax
Constraint Considerations
Digital signatures only work if the verification calculations
are performed on exactly the same bits as the signing calculations.
If the surface representation of the signed data can change between
signing and verification, then some way to standardize the
changeable aspect must be used before signing and verification. For
example, even for simple ASCII text there are at least three widely
used line ending sequences. If it is possible for signed text to be
modified from one line ending convention to another between the
time of signing and signature verification, then the line endings
need to be canonicalized to a standard form before signing and
verification or the signatures will break.
XML is subject to surface representation changes and to
processing which discards some surface information. For this
reason, XML digital signatures have a provision for indicating
canonicalization methods in the signature so that a verifier can
use the same canonicalization as the signer.
Throughout this specification we distinguish between the
canonicalization of a Signature element and other
signed XML data objects. It is possible for an isolated XML
document to be treated as if it were binary data so that no changes
can occur. In that case, the digest of the document will not change
and it need not be canonicalized if it is signed and verified as
such. However, XML that is read and processed using standard XML
parsing and processing techniques is frequently changed such that
some of its surface representation information is lost or modified.
In particular, this will occur in many cases for the
Signature and enclosed SignedInfo
elements since they, and possibly an encompassing XML document,
will be processed as XML.
Similarly, these considerations apply to Manifest,
Object, and SignatureProperties elements
if those elements have been digested, their
DigestValue is to be checked, and they are being
processed as XML.
The kinds of changes in XML that may need to be canonicalized
can be divided into four categories. There are those related to the
basic [XML], as described in 7.1 below.
There are those related to [DOM], [SAX], or similar processing as described in 7.2
below. Third, there is the possibility of coded character set
conversion, such as between UTF-8 and UTF-16, both of which
all [XML] compliant processors are
required to support, which is described in the paragraph
immediately below. And, fourth, there are changes that related to
namespace declaration and xml namespace attribute context as
described in 7.3 below.
Any canonicalization algorithm should yield output in a specific
fixed coded character set. All canonicalization algorithms identified in this document use
UTF-8 (without a byte order mark (BOM)) and do not provide
character normalization. We RECOMMEND that signature applications
create XML content (Signature elements and their
descendents/content) in Normalization Form C [NFC, NFC-Corrigendum] and check that any
XML being consumed is in that form as well; (if not, signatures may
consequently fail to validate). Additionally, none of these
algorithms provide data type normalization. Applications that
normalize data types in varying formats (e.g., (true, false) or
(1,0)) may not be able to validate each other's signatures.
7.1 XML 1.0, Syntax
Constraints, and Canonicalization
XML 1.0 [XML] defines an interface where
a conformant application reading XML is given certain information
from that XML and not other information. In particular,
- line endings are normalized to the single character #xA by
dropping #xD characters if they are immediately followed by a #xA
and replacing them with #xA in all other cases,
- missing attributes declared to have default values are provided
to the application as if present with the default value,
- character references are replaced with the corresponding
character,
- entity references are replaced with the corresponding declared
entity,
- attribute values are normalized by
- replacing character and entity references as above,
- replacing occurrences of #x9, #xA, and #xD with #x20 (space)
except that the sequence #xD#xA is replaced by a single space,
and
- if the attribute is not declared to be CDATA, stripping all
leading and trailing spaces and replacing all interior runs of
spaces with a single space.
Note that items (2), (4), and (5C) depend on the presence of a
schema, DTD or similar declarations. The Signature
element type is
laxly schema valid [XML-schema],
consequently external XML or even XML within the same document as
the signature may be (only) well-formed or from another namespace
(where permitted by the signature schema); the noted items may not
be present. Thus, a signature with such content will only be
verifiable by other signature applications if the following syntax
constraints are observed when generating any signed material
including the SignedInfo element:
- attributes having default values be explicitly present,
- all entity references (except "amp", "lt", "gt", "apos",
"quot", and other character entities not representable in the
encoding chosen) be expanded,
- attribute value white space be normalized
7.2 DOM/SAX
Processing and Canonicalization
In addition to the canonicalization and syntax constraints
discussed above, many XML applications use the Document Object
Model [DOM] or The Simple API for XML
[SAX]. DOM maps XML into a tree structure of
nodes and typically assumes it will be used on an entire document
with subsequent processing being done on this tree. SAX converts
XML into a series of events such as a start tag, content, etc. In
either case, many surface characteristics such as the ordering of
attributes and insignificant white space within start/end tags is
lost. In addition, namespace declarations are mapped over the nodes
to which they apply, losing the namespace prefixes in the source
text and, in most cases, losing where namespace declarations
appeared in the original instance.
If an XML Signature is to be produced or verified on a system
using the DOM or SAX processing, a canonical method is needed to
serialize the relevant part of a DOM tree or sequence of SAX
events. XML canonicalization specifications, such as [XML-C14N], are based only on information
which is preserved by DOM and SAX. For an XML Signature to be
verifiable by an implementation using DOM or SAX, not only must the
XML 1.0 syntax constraints given in the
previous section be followed but an appropriate XML
canonicalization MUST be specified so that the verifier can
re-serialize DOM/SAX mediated input into the same octet stream that
was signed.
In [XPath] and consequently the
Canonical XML data model an element has namespace nodes that
correspond to those declarations within the element and its
ancestors:
"Note: An element E has namespace nodes
that represent its namespace declarations as well as any
namespace declarations made by its ancestors that have not been
overridden in E's declarations, the default namespace
if it is non-empty, and the declaration of the prefix
xml." [XML-C14N]
When serializing a Signature element or signed XML
data that's the child of other elements using these data models,
that Signature element and its children, may contain
namespace declarations from its ancestor context. In addition, the
Canonical XML and Canonical XML with Comments algorithms import all
xml namespace attributes (such as xml:lang) from the
nearest ancestor in which they are declared to the apex node of
canonicalized XML unless they are already declared at that node.
This may frustrate the intent of the signer to create a signature
in one context which remains valid in another. For example, given a
signature which is a child of B and a grandchild of
A:
<A xmlns:n1="&foo;">
<B xmlns:n2="&bar;">
<Signature xmlns="&dsig;"> ...
<Reference URI="#signme"/> ...
</Signature>
<C ID="signme" xmlns="&baz;"/>
</B>
</A>
when either the element B or the signed element
C is moved into a [SOAP]
envelope for transport:
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
...
<SOAP:Body>
<B xmlns:n2="&bar;">
<Signature xmlns="&dsig;">
...
</Signature>
<C ID="signme" xmlns="&baz;"/>
</B>
</SOAP:Body>
</SOAP:Envelope>
The canonical form of the signature in this context will contain
new namespace declarations from the SOAP:Envelope
context, invalidating the signature. Also, the canonical form will
lack namespace declarations it may have originally had from element
A's context, also invalidating the signature. To avoid
these problems, the application may:
- Rely upon the enveloping application to properly divorce its
body (the signature payload) from the context (the envelope) before
the signature is validated. Or,
- Use a canonicalization method that "repels/excludes" instead of
"attracts" ancestor context. [XML-C14N]
purposefully attracts such context.
The XML Signature specification provides a very flexible digital
signature mechanism. Implementors must give consideration to their
application threat models and to the following factors.
A requirement of this specification is to permit signatures to
"apply to a part or totality of a XML document." (See [XML-Signature-RD, section 3.1.3].)
The Transforms mechanism meets this requirement by
permitting one to sign data derived from processing the content of
the identified resource. For instance, applications that wish to
sign a form, but permit users to enter limited field data without
invalidating a previous signature on the form might use [XPath] to exclude those portions the user
needs to change. Transforms may be arbitrarily
specified and may include encoding tranforms, canonicalization
instructions or even XSLT transformations. Three cautions are
raised with respect to this feature in the following sections.
Note, core
validation behavior does not confirm that the signed data was
obtained by applying each step of the indicated transforms. (Though
it does check that the digest of the resulting content matches that
specified in the signature.) For example, some application
may be satisfied with verifying an XML signature over a cached copy
of already transformed data. Other applications might require that
content be freshly dereferenced and transformed.
First, obviously, signatures over a transformed document do not
secure any information discarded by transforms: only what is signed
is secure.
Note that the use of Canonical XML [XML-C14N] ensures that all internal
entities and XML namespaces are expanded within the content being
signed. All entities are replaced with their definitions and the
canonical form explicitly represents the namespace that an element
would otherwise inherit. Applications that do not canonicalize XML
content (especially the SignedInfo element) SHOULD NOT
use internal entities and SHOULD represent the namespace explicitly
within the content being signed since they can not rely upon
canonicalization to do this for them. Also, users concerned with
the integrity of the element type definitions associated with the
XML instance being signed may wish to sign those definitions as
well (i.e,. the schema, DTD, or natural language description
associated with the namespace/identifier).
Second, an envelope containing signed information is not secured
by the signature. For instance, when an encrypted envelope contains
a signature, the signature does not protect the authenticity or
integrity of unsigned envelope headers nor its ciphertext form, it
only secures the plaintext actually signed.
Additionally, the signature secures any information introduced
by the transform: only what is "seen" (that which is represented to
the user via visual, auditory or other media) should be signed. If
signing is intended to convey the judgment or consent of a user (an
automated mechanism or person), then it is normally necessary to
secure as exactly as practical the information that was presented
to that user. Note that this can be accomplished by literally
signing what was presented, such as the screen images shown a user.
However, this may result in data which is difficult for subsequent
software to manipulate. Instead, one can sign the data along with
whatever filters, style sheets, client profile or other information
that affects its presentation.
Just as a user should only sign what he or she "sees," persons
and automated mechanism that trust the validity of a transformed
document on the basis of a valid signature should operate over the
data that was transformed (including canonicalization) and signed,
not the original pre-transformed data. This recommendation applies
to transforms specified within the signature as well as those
included as part of the document itself. For instance, if an XML
document includes an
embedded style sheet [XSLT] it is the
transformed document that should be represented to the user and
signed. To meet this recommendation where a document references an
external style sheet, the content of that external resource should
also be signed as via a signature Referenceotherwise
the content of that external content might change which alters the
resulting document without invalidating the signature.
Some applications might operate over the original or
intermediary data but should be extremely careful about potential
weaknesses introduced between the original and transformed data.
This is a trust decision about the character and meaning of the
transforms that an application needs to make with caution. Consider
a canonicalization algorithm that normalizes character case (lower
to upper) or character composition ('e and accent' to
'accented-e'). An adversary could introduce changes that are
normalized and consequently inconsequential to signature validity
but material to a DOM processor. For instance, by changing the case
of a character one might influence the result of an XPath
selection. A serious risk is introduced if that change is
normalized for signature validation but the processor operates over
the original data and returns a different result than intended.
As a result of this, while we RECOMMEND all documents operated
upon and generated by signature applications be in [NFC, NFC-Corrigendum] (otherwise
intermediate processors might unintentionally break the signature)
encoding normalizations SHOULD NOT be done as part of a signature
transform, or (to state it another way) if normalization does
occur, the application SHOULD always "see" (operate over) the
normalized form.
This specification uses public key signatures and keyed hash
authentication codes. These have substantially different security
models. Furthermore, it permits user specified algorithms which may
have other models.
With public key signatures, any number of parties can hold the
public key and verify signatures while only the parties with the
private key can create signatures. The number of holders of the
private key should be minimized and preferably be one. Confidence
by verifiers in the public key they are using and its binding to
the entity or capabilities represented by the corresponding private
key is an important issue, usually addressed by certificate or
online authority systems.
Keyed hash authentication codes, based on secret keys, are
typically much more efficient in terms of the computational effort
required but have the characteristic that all verifiers need to
have possession of the same key as the signer. Thus any verifier
can forge signatures.
This specification permits user provided signature algorithms
and keying information designators. Such user provided algorithms
may have different security models. For example, methods involving
biometrics usually depend on a physical characteristic of the
authorized user that can not be changed the way public or secret
keys can be and may have other security model differences.
8.3 Algorithms, Key
Lengths, Certificates, Etc.
The strength of a particular signature depends on all links in
the security chain. This includes the signature and digest
algorithms used, the strength of the key generation [RANDOM] and the size of the key, the
security of key and certificate authentication and distribution
mechanisms, certificate chain validation policy, protection of
cryptographic processing from hostile observation and tampering,
etc.
Care must be exercised by applications in executing the various
algorithms that may be specified in an XML signature and in the
processing of any "executable content" that might be provided to
such algorithms as parameters, such as XSLT transforms. The
algorithms specified in this document will usually be implemented
via a trusted library but even there perverse parameters might
cause unacceptable processing or memory demand. Even more care may
be warranted with application defined algorithms.
The security of an overall system will also depend on the
security and integrity of its operating procedures, its personnel,
and on the administrative enforcement of those procedures. All the
factors listed in this section are important to the overall
security of a system; however, most are beyond the scope of this
specification.
9.0 Schema, DTD, Data
Model, and Valid Examples
- XML Signature Schema Instance
- xmldsig-core-schema.xsd
- Valid XML schema instance based on the 20001024 Schema/DTD [XML-Schema].
- XML Signature DTD
- xmldsig-core-schema.dtd
- RDF Data Model
- xmldsig-datamodel-20000112.gif
- XML Signature Object Example
- signature-example.xml
- A cryptographical fabricated XML example that includes foreign
content and validates under the schema, it also uses
schemaLocation to aid automated schema fetching and
validation.
- RSA XML Signature Example
- signature-example-rsa.xml
- An XML Signature example with generated cryptographic values by
Merlin Hughes and validated by Gregor Karlinger.
- DSA XML Signature Example
- signature-example-dsa.xml
- Similar to above but uses DSA.
- Authentication Code (Protected
Checksum)
- A value generated from the application of a shared key to a
message via a cryptographic algorithm such that it has the
properties of message authentication (and integrity) but not signer
authentication. Equivalent to protected checksum, "A
checksum that is computed for a data object by means that protect
against active attacks that would attempt to change the checksum to
make it match changes made to the data object." [SEC]
- Authentication, Message
- The property, given an authentication code/protected
checksum, that tampering with both the data and checksum, so as
to introduce changes while seemingly preserving integrity, are still
detected. "A signature should identify what is signed, making it
impracticable to falsify or alter either the signed matter or the
signature without detection." [Digital
Signature Guidelines, ABA].
- Authentication, Signer
- The property that the identity of the signer is as claimed. "A
signature should indicate who signed a document, message or record,
and should be difficult for another person to produce without
authorization." [Digital
Signature Guidelines, ABA] Note, signer
authentication is an application decision (e.g., does the signing
key actually correspond to a specific identity) that is supported
by, but out of scope, of this specification.
- Checksum
- "A value that (a) is computed by a function that is dependent
on the contents of a data object and (b) is stored or transmitted
together with the object, for the purpose of detecting changes in
the data." [SEC]
- Core
- The syntax and processing defined by this specification,
including core
validation. We use this term to distinguish other markup,
processing, and applications semantics from our own.
- Data Object
(Content/Document)
- The actual binary/octet data being operated on (transformed,
digested, or signed) by an application -- frequently an HTTP
entity [HTTP]. Note that the proper
noun
Object designates a specific XML element.
Occasionally we refer to a data object as a document or as
a resource's
content. The term element content is used to describe
the data between XML start and end tags [XML]. The term XML document is used to
describe data objects which conform to the XML specification [XML].
- Integrity
- "The property that data has not been changed, destroyed, or
lost in an unauthorized or accidental manner." [SEC] A simple checksum can provide integrity from incidental
changes in the data; message authentication is similar but also
protects against an active attack to alter the data whereby a
change in the checksum is introduced so as to match the change in
the data.
- Object
- An XML Signature element wherein arbitrary (non-core) data may be placed. An
Object element is merely one type of digital data (or
document) that can be signed via a Reference.
- Resource
- "A resource can be anything that has identity. Familiar
examples include an electronic document, an image, a service (e.g.,
'today's weather report for Los Angeles'), and a collection of
other resources.... The resource is the conceptual mapping to an
entity or set of entities, not necessarily the entity which
corresponds to that mapping at any particular instance in time.
Thus, a resource can remain constant even when its content---the
entities to which it currently corresponds---changes over time,
provided that the conceptual mapping is not changed in the
process." [URI] In order to avoid a
collision of the term entity within the URI and XML
specifications, we use the term data object,
content or document to refer to the actual
bits/octets being operated upon.
- Signature
- Formally speaking, a value generated from the application of a
private key to a message via a cryptographic algorithm such that it
has the properties of integrity, message
authentication and/or signer authentication. (However, we sometimes
use the term signature generically such that it encompasses Authentication
Code values as well, but we are careful to make the distinction
when the property of signer authentication is relevant to the
exposition.) A signature may be (non-exclusively) described as detached, enveloping, or
enveloped.
- Signature, Application
- An application that implements the MANDATORY (REQUIRED/MUST)
portions of this specification; these conformance requirements are
over application behaviour, the structure of the
Signature element type and its children (including
SignatureValue) and the specified algorithms.
- Signature, Detached
- The signature is over content external to the
Signature element, and can be identified via a
URI or transform. Consequently, the signature is
"detached" from the content it signs. This definition typically
applies to separate data objects, but it also includes the instance
where the Signature and data object reside within the
same XML document but are sibling elements.
- Signature, Enveloping
- The signature is over content found within an
Object element of the signature itself. The
Object (or its content) is identified via a
Reference (via a URI fragment identifier
or transform).
- Signature, Enveloped
- The signature is over the XML content that contains the
signature as an element. The content provides the root XML document
element. Obviously, enveloped signatures must take care not to
include their own value in the calculation of the
SignatureValue.
- Transform
- The processing of a data from its source to its derived form.
Typical transforms include XML Canonicalization, XPath, and
XSLT.
- Validation, Core
- The core processing requirements of this specification
requiring signature validation and
SignedInfo reference validation.
- Validation, Reference
- The hash value of the identified and transformed content,
specified by
Reference, matches its specified
DigestValue.
- Validation, Signature
- The
SignatureValue matches the result of
processing SignedInfo with
CanonicalizationMethod and
SignatureMethod as specified in Core Validation (section 3.2).
- Validation,
Trust/Application
- The application determines that the semantics associated with a
signature are valid. For example, an application may validate the
time stamps or the integrity of the signer key -- though this
behavior is external to this core specification.
- ABA
- Digital
Signature Guidelines.
http://www.abanet.org/scitech/ec/isc/dsgfree.html
- DOM
- Document
Object Model (DOM) Level 1 Specification. W3C Recommendation.
V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le
Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, L. Wood. October
1998.
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/
- DSS
-
FIPS PUB 186-2 . Digital Signature Standard (DSS). U.S.
Department of Commerce/National Institute of Standards and
Technology.
http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf
- HMAC
- RFC 2104 .
HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk,
M. Bellare, R. Canetti. February 1997.
http://www.ietf.org/rfc/rfc2104.txt
- HTTP
- RFC
2616 . Hypertext Transfer Protocol -- HTTP/1.1. J.
Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
Berners-Lee. June 1999.
http://www.ietf.org/rfc/rfc2616.txt
- KEYWORDS
- RFC 2119
Key words for use in RFCs to Indicate Requirement Levels. S.
Bradner. March 1997.
http://www.ietf.org/rfc/rfc2119.txt
- LDAP-DN
- RFC 2253 .
Lightweight Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names. M. Wahl, S. Kille, T.
Howes. December 1997.
http://www.ietf.org/rfc/rfc2253.txt
- MD5
- RFC 1321 .
The MD5 Message-Digest Algorithm. R. Rivest. April
1992.
http://www.ietf.org/rfc/rfc1321.txt
- MIME
- RFC 2045 .
Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies. N. Freed & N. Borenstein. November
1996.
http://www.ietf.org/rfc/rfc2045.txt
- NFC
- TR15, Unicode Normalization Forms. M. Davis, M.
Dürst. Revision 18: November 1999. http://www.unicode.org/unicode/reports/tr15/tr15-18.html.
- NFC-Corrigendum
- Normalization Corrigendum . The Unicode Consortium.
http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html.
- PGP
- RFC 2440
OpenPGP Message Format. J. Callas, L. Donnerhacke, H.
Finney, R. Thayer. November 1998.
http://www.ietf.org/rfc/rfc2440.txt
- RANDOM
- RFC 1750
Randomness Recommendations for Security. D. Eastlake, S.
Crocker, J. Schiller. December 1994.
http://www.ietf.org/rfc/rfc1750.txt
- RDF
- RDF
Schema W3C Candidate Recommendation. D. Brickley, R.V. Guha.
March 2000.
http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
- RDF Model
and Syntax W3C Recommendation. O. Lassila, R. Swick. February
1999.
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
- 1363
- IEEE 1363: Standard Specifications for Public Key Cryptography.
August 2000.
- PKCS1
- RFC 2437 .
PKCS #1: RSA Cryptography Specifications Version 2.0. B.
Kaliski, J. Staddon. October 1998.
http://www.ietf.org/rfc/rfc2437.txt
- SAX
- SAX: The
Simple API for XML David Megginson et al. May 1998.
http://www.megginson.com/SAX/index.html
- SEC
- RFC 2828 .
Internet Security Glossary. R. Shirey. May 2000.
http://www.faqs.org/rfcs/rfc2828.html
- SHA-1
-
FIPS PUB 180-1 . Secure Hash Standard. U.S. Department
of Commerce/National Institute of Standards and Technology.
http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt
- SOAP
- Simple
Object Access Protocol (SOAP) Version 1.1 . W3C Note. D. Box,
D. Ehnebuske, G. Kakivaya, A.
Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte, D. Winer.
May 2001.
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
- Unicode
- The Unicode Consortium. The Unicode
Standard.
http://www.unicode.org/unicode/standard/standard.html
- UTF-16
- RFC 2781 .
UTF-16, an encoding of ISO 10646. P. Hoffman , F. Yergeau.
February 2000.
http://www.ietf.org/rfc/rfc2781.txt
- UTF-8
- RFC 2279 .
UTF-8, a transformation format of ISO 10646. F. Yergeau.
January 1998.
http://www.ietf.org/rfc/rfc2279.txt
- URI
- RFC 2396 .
Uniform Resource Identifiers (URI): Generic Syntax. T.
Berners-Lee, R. Fielding, L. Masinter. August 1998.
http://www.ietf.org/rfc/rfc2396.txt
- URI-Literal
- RFC 2732 .
Format for Literal IPv6 Addresses in URL's. R. Hinden, B.
Carpenter, L. Masinter. December 1999.
http://www.ietf.org/rfc/rfc2732.txt
- URL
- RFC 1738.
Uniform Resource Locators (URL). Berners-Lee, T., Masinter,
L., and M. McCahill. December 1994.
http://www.ietf.org/rfc/rfc1738.txt
- URN
- RFC 2141 .
URN Syntax. R. Moats. May 1997.
http://www.ietf.org/rfc/rfc2141.txt
- RFC 2611 .
URN Namespace Definition Mechanisms. L. Daigle, D. van
Gulik, R. Iannella, P. Falstrom. June 1999.
http://www.ietf.org/rfc/rfc2611.txt
- X509v3
- ITU-T Recommendation X.509 version 3 (1997). "Information
Technology - Open Systems Interconnection - The Directory
Authentication Framework" ISO/IEC 9594-8:1997.
- XHTML 1.0
- XHTML(tm)
1.0: The Extensible Hypertext Markup Language W3C
Recommendation. S. Pemberton, D. Raggett, et al. January
2000.
http://www.w3.org/TR/2000/REC-xhtml1-20000126/
- XLink
- XML
Linking Language. W3C Proposed Recommendation. S. DeRose, E.
Maler, D. Orchard June 2001.
http://www.w3.org/TR/2000/REC-xlink-20010627/
- XML
- Extensible
Markup Language (XML) 1.0 . W3C Recommendation. T. Bray, J.
Paoli, C. M. Sperberg-McQueen. February 1998.
- http://www.w3.org/TR/1998/REC-xml-19980210
- XML-C14N
- Canonical
XML. W3C Recommendation. J. Boyer. March 2001.
- http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.ietf.org/rfc/rfc3076.txt
- XML-Japanese
- XML
Japanese Profile . W3C Note. M. MURATA April 2000 http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/
- XML-MT
- RFC 2376 .
XML Media Types. E. Whitehead, M. Murata. July 1998.
http://www.ietf.org/rfc/rfc2376.txt
- XML-ns
- Namespaces
in XML W3C Recommendation. T. Bray, D. Hollander, A. Layman.
Janaury 1999.
- http://www.w3.org/TR/1999/REC-xml-names-19990114
- XML-schema
- XML
Schema Part 1: Structures W3C Recommendation. D. Beech, M.
Maloney, N. Mendelsohn, H. Thompson. May 2001.
- http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML
Schema Part 2: Datatypes W3C Recommendation. P. Biron, A.
Malhotra. May 2001.
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
- XML-Signature-RD
- RFC 2807 . XML Signature
Requirements. W3C Working Draft. J. Reagle, April 2000.
http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014
http://www.ietf.org/rfc/rfc2807.txt
- XPath
- XML Path
Language (XPath) Version 1.0 . W3C Recommendation. J. Clark, S.
DeRose. October 1999.
http://www.w3.org/TR/1999/REC-xpath-19991116
- XPointer
- XML
Pointer Language (XPointer) . W3C Working Draft. S. DeRose, R.
Daniel, E. Maler. January 2001.
http://www.w3.org/TR/2001/WD-xptr-20010108
- XSL
- Extensible
Stylesheet Language (XSL) W3C Candidate Recommendation. S.
Adler, A. Berglund, J. Caruso, S. Deach, P. Grosso, E. Gutentag, A.
Milowski, S. Parnell, J. Richman, S. Zilles. October 2000.
http://www.w3.org/TR/2000/CR-xsl-20001121/
- XSLT
- XSL
Transforms (XSLT) Version 1.0 . W3C Recommendation. J. Clark.
November 1999.
- http://www.w3.org/TR/1999/REC-xslt-19991116.html
Donald E. Eastlake 3rd
Motorola, 20 Forbes Boulevard
Mansfield, MA 02048 USA
Phone: 1-508-261-5434
Email: Donald.Eastlake@motorola.com
Joseph M. Reagle Jr., W3C
Massachusetts Institute of Technology
Laboratory for Computer Science
NE43-350, 545 Technology Square
Cambridge, MA 02139
Phone: + 1.617.258.7621
Email: reagle@w3.org
David Solo
Citigroup
909 Third Ave, 16th Floor
NY, NY 10043 USA
Phone +1-212-559-2900
Email: dsolo@alum.mit.edu
