Java XMLデジタル署名API仕様(JSR 105)

目次

はじめに

このドキュメントでは、Java XMLデジタル署名API仕様(JSR 105)について説明します。このJSRの目的は、XML署名を生成および検証するための標準のJava APIを定義することです。

この仕様が完成すると、このAPIの機能について説明するリファレンス実装が作成されることになり、この仕様のオペレーションの定義が提供されます。この仕様の実装に対応しているかどうかを確認するためのTechnology Compatibility Kit (TCK)も使用可能になります。Java Community Process 2.1に従ってこれらが必要になります。

JSR 105 APIは、次の2種類のユーザーをターゲットにしています。

謝辞

JSR 105エキスパート・グループ: また、次のメンバーにも感謝を捧げます。Sun MicrosystemsのValerie Peng、Vincent Ryan、Sharon Liu、Chok Poh、K. Venugopal Rao.、Paul Rank、Alexey Gavrilov、Bill Situ、Eric Jendrock、Andrew Fan、Manveen Kaur、Tom Amiro、Michael Mi、Dmitri Silaev、Roman Makarchuk、Vanitha Venkatraman, Arkadiy Sutchilin, Scott Fordin、ApacheのVishal Mahajan、IAIKのMartin Centner。

要件

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119に説明されているとおりに解釈されます。
  1. W3C Recommendation, XML-Signature Syntax and Processing
    • APIを使用して、プログラマはW3C勧告で規定されているSHOULDおよびMUSTのすべての要件を満たすXML署名を生成および検証できる必要があります。
    • APIを使用して、W3C勧告で規定されているSHOULDおよびMUSTのすべての要件を満たすAPIの実装を作成できる必要があります。
  2. 実装は、W3C Recommendation, XML-Signature XPath Filter Transform 2.0をサポートする必要があります。
  3. 実装は、W3C Recommendation, Exclusive XML Canonicalization Version 1.0をサポートする必要があります。
  4. DOMに依存しないAPI。APIは、DOMなどの特定のXML表現に依存していない必要があります。DOM、JDOM、dom4jなどの異なるXML処理やメカニズム表現に対してAPI実装を作成できる必要があります。
  5. 拡張可能なプロバイダ・ベースのAPI。サード・パーティが、暗号化アルゴリズムや変換アルゴリズムの管理や作成、URIの間接参照、およびXMLのオブジェクトの整列化を行う実装を作成およびプラグインすることができる必要があります。
  6. デフォルトのXMLメカニズム・タイプDOMのサポート。実装は、デフォルトのメカニズム・タイプDOMを最低限サポートする必要があります。これにより、JSR 105のすべての実装で最低レベルの機能性が保証されます。実装は、ほかのメカニズム・タイプもサポートできます。
  7. デフォルトのXMLメカニズム・タイプDOMの相互運用性。APIは、DOM実装を使用するアプリケーションで移植性および相互運用性を保証する必要があります。
  8. J2SE要件。このテクノロジの実装はJ2SE 1.2以降をサポートできますが、最低限J2SEのバージョン1.4をサポートする必要があります。

API依存

目標にしない事項

  1. 非DOM実装のサポート。APIでは非DOM実装を作成できる必要がありますが、DOM以外の実装間での相互運用性を保証することは最初のバージョンの範囲外です。追加の標準サービス・プロバイダ・タイプが今後追加されたり、JSR 105の保守バージョンで必要なAPIの拡張機能が検討される可能性があります。
  2. 高レベルのAPIのサポート。プログラマは、JSR 105 APIに基づいて構築される高レベルのAPIを設計して、低レベルの詳細を非表示にしたり、共通のユース・ケースに対処したり、プロファイリングの制限を適用できます。ただし、これらの要件をサポートすることは最初のバージョンの範囲外です。高レベルのAPIは、JSR 105の保守リリースで考慮される可能性があります。
  3. ユーザープラガブル・アルゴリズム(javax.xml.crypto.dsig.TransformServiceクラスでサポートされている変換アルゴリズムおよび正規化アルゴリズム以外)のサポート。開発者が完全なJSR 105実装を作成せずに独自のXML署名アルゴリズムの実装をプラグインできるようにすることは、有用なことだと考えられますが、JSR 105のこのリリースでは必要ありません。Java SEの後続リリースでは、基礎となるJCA/JCEを拡張して、XMLセキュリティ・アルゴリズム、パラメータ、鍵情報の登録、解析および処理のサポートを追加するソリューションを検討しています。

パッケージの概要

JSR 105 APIは、次の6つのパッケージで構成されています。 javax.xml.cryptoパッケージには、XML署名の生成やXMLデータの暗号化など、XML暗号化操作を行う場合に使用する共通クラスが含まれています。このパッケージ内の主要なクラスには次の2つがあります。KeySelectorクラスを使用すると、開発者は、KeyInfoオブジェクトに含まれている情報を使用して鍵を検出して任意に検証する実装を提供できます。URIDereferencerクラスを使用すると、開発者は、独自のURI間接参照実装を作成および指定できます。

javax.xml.crypto.dsigパッケージには、W3C XMLデジタル署名仕様で定義されているコア要素を表すインタフェースが含まれています。もっとも重要なのはXMLSignatureクラスです。このクラスを使用すると、XMLデジタル署名の署名および検証を行うことができます。ほとんどのXML署名構造または要素は、対応するインタフェースによって表されます(KeyInfo構造を除きます。これは独自のパッケージに含まれており、次の段落で説明します)。これらのインタフェースには、SignedInfo、 CanonicalizationMethod、SignatureMethod、Reference、Transform、DigestMethod、XMLObject、Manifest、SignaturePropertyおよびSignaturePropertiesが含まれます。XMLSignatureFactoryクラスは、これらのインタフェースを実装するオブジェクトを作成するために使用する抽象ファクトリです。

javax.xml.crypto.dsig.keyinfoパッケージには、W3C XMLデジタル署名勧告で定義されているほとんどのKeyInfo構造を表すインタフェースが含まれています。この構造には、KeyInfo、KeyName、KeyValue、X509Data、X509IssuerSerial、RetrievalMethodおよびPGPDataがあります。KeyInfoFactoryクラスは、これらのインタフェースを実装するオブジェクトを作成するために使用する抽象ファクトリです。

javax.xml.crypto.dsig.specパッケージには、ダイジェスト、署名、変換、またはXML署名の処理で使用される正規化アルゴリズム用の入力パラメータを表すインタフェースおよびクラスが含まれています。

最後に、javax.xml.crypto.domおよびjavax.xml.crypto.dsig.domパッケージには、javax.xml.cryptoおよびjavax.xml.crypto.dsigパッケージ用のDOM固有のクラスが含まれています。DOMベースのXMLSignatureFactoryまたはKeyInfoFactory実装を作成または使用する開発者およびユーザーのみが、これらのパッケージを直接使用する必要があります。

サービス・プロバイダ

JSR 105暗号化サービスは、XMLSignatureFactoryおよびKeyInfoFactory抽象クラスの固定実装であり、XML署名やKeyInfo構造を解析、生成、および検証するオブジェクトやアルゴリズムを作成します。XMLSignatureFactoryの固定実装は、XML署名に関するW3C勧告に規定されているように、必要なそれぞれのアルゴリズムをサポートしている必要があります。この固定実装は、W3C勧告やほかの仕様に規定されているように、ほかのアルゴリズムをサポートできます。

JSR 105は、JCAプロバイダ・モデルを使用してXMLSignatureFactoryおよびKeyInfoFactory実装の登録とロードを行います。

固定実装XMLSignatureFactoryまたはKeyInfoFactoryはそれぞれ、XML署名やKeyInfo構造を解析および生成するときに実装によって内部で使用されるXML処理メカニズムを識別する特定のXMLメカニズム・タイプをサポートしています。このJSRは標準タイプDOMをサポートしています。新しい標準タイプ(JDOMなど)のサポートは、今後追加される可能性があります。

JSR 105実装は、java.security.Signatureやjava.security.MessageDigestなどのベースとなるJCAエンジン・クラスを使用して暗号化操作を行う必要があります。

XMLSignatureFactoryおよびKeyInfoFactoryクラス以外に、JSR 105は、変換および正規化アルゴリズム用のサービス・プロバイダ・インタフェースもサポートしています。TransformServiceクラスを使用すると、特定のXMLメカニズム・タイプ用の固有の変換または正規化アルゴリズムの実装を開発およびプラグインすることができます。TransformServiceクラスは、実装を登録およびロードするときに標準JCAプロバイダ・モデルを使用します。各JSR 105実装はTransformServiceクラスを使用して、生成または検証しているXML署名で変換アルゴリズムおよび正規化アルゴリズムをサポートするプロバイダを見つける必要があります。

DOMメカニズムの要件

相互運用性の問題を最小限にするために、DOMベースのXMLSignatureFactory、KeyInfoFactory、またはTransformServiceを実装する場合は、次の要件に従う必要があります。
  1. XMLSignatureFactoryのunmarshalXMLSignatureメソッドはDOMValidateContext型をサポートする必要があります。型がDOMValidateContextの場合はSignature型の要素を含む必要があります。また、unmarshalXMLSignatureメソッドは渡されるDOMValidateContextのID/要素マッピングを生成できます。
  2. XMLSignatureFactoryによって生成されるXMLSignatureのsignメソッドはDOMSignContext型をサポートし、validateメソッドはDOMValidateContext型をサポートする必要があります。この要件は、SignatureValueのvalidateメソッドおよびReferenceのvalidateメソッドにも当てはまります。
  3. 実装は、アプリケーションが拡張可能なコンテンツ(任意の要素または混合コンテンツ)を指定するためのメカニズムとしてDOMStructureをサポートする必要があります。
  4. ユーザー指定のURIDereferencerのdereferenceメソッドがNodeSetDataオブジェクトを返す場合、iteratorメソッドは型org.w3c.dom.Nodeのオブジェクトの繰返しを返す必要があります。
  5. ユーザー指定のURIDereferencerのdereferenceメソッドに渡されたURIReferenceオブジェクトは型DOMURIReferenceであり、XMLCryptoContextオブジェクトはDOMCryptoContextを実装する必要があります。
  6. 直前の2つの要件は、XMLSignatureFactoryおよびKeyInfoFactoryのgetURIDereferencerメソッドによって返されるURIDereferencerにも当てはまります。
  7. KeyInfoFactoryのunmarshalKeyInfoメソッドはDOMStructure型をサポートする必要があります。型がDOMStructureの場合はKeyInfo型の要素を含む必要があります。
  8. TransformのtransformメソッドはDOMCryptoContextコンテキスト・パラメータ型をサポートする必要があります。
  9. XMLSignatureFactoryのnewtransformおよびnewCanonicalizationMethodメソッドはDOMStructureパラメータ型をサポートする必要があります。
  10. TransformServiceのinitおよびmarshalParamsメソッドはDOMStructureおよびDOMCryptoContext型をサポートする必要があります。
  11. XMLSignatureFactoryのunmarshalXMLSignatureメソッドはDOMStructure型をサポートする必要があります。型がDOMStructureの場合はSignature型の要素を含む必要があります。
  12. KeyInfoのmarshalメソッドはDOMStructureおよびDOMCryptoContextパラメータ型をサポートする必要があります。
DOM実装は、相互運用性に影響しない場合、DOM以外のXML解析APIを内部的に使用できます。たとえば、XMLSignatureFactoryのDOM実装は、内部的にSAXパーサーを使用してデータを正規化することができます。

オープンAPIの問題

オープンAPIの問題は、次のとおりです。
  1. 外部XMLドキュメント参照のID属性の登録がサポートされていません。
    次の参照について検討してみます。 
    
  <Reference URI="document.xml">
    <Transforms>
      <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
        <XPath>id("foo")</XPath>
      </Transform>
    </Transforms>
  </Reference>
    外部ドキュメントの間接参照によってオクテット・ストリームが生成され、それがJSR 105実装によってNodeSetに変換されています。ただし、APIでは外部ドキュメントのID属性を登録するためのメカニズムが提供されていないため、XPath変換実装は「foo」IDを識別できない可能性があります。

プログラミング例

次の例1 - 3では、JSR 105 APIを使用してさまざまなタイプの単純なXMLデジタル署名を生成する方法について説明します。例1では、DSA署名アルゴリズムを使用して分離署名を生成する方法について説明します。例2では、エンベロープされた署名を生成する方法について説明します。例3では、エンベロープする署名を生成する方法について説明します。例4では、XML署名を検証する方法について説明します。
  1. 分離されたXMLデジタル署名の生成
  2. エンベロープされたXMLデジタル署名の生成
  3. エンベロープするXMLデジタル署名の生成
  4. XMLデジタル署名の検証
Copyright © 1993, 2020, Oracle and/or its affiliates. All rights reserved.