Java(TM) Certification Path API プログラマーズガイド

Java^TM Certification Path API プログラマーズガイド

著者: Sean Mullan

最終更新日: 2002 年 2 月 8 日

コアクラスとインタフェース

PKIX クラス

TrustAnchor クラス
PKIXParameters クラス
PKIXCertPathValidatorResult クラス
PolicyNode インタフェースおよび PolicyQualifierInfo クラス
PKIXBuilderParameters クラス
PKIXCertPathBuilderResult クラス
PKIXCertPathChecker クラス

J2SE 1.4 Beta からの変更点

TrustAnchor(X509Certificate, byte[]) コンストラクタが InvalidAlgorithmParameterException の代わりに IllegalArgumentException をスローするようになった (RuntimeException なので javadoc 内でのみ)
TrustAnchor(String, PublicKey, byte[]) コンストラクタが InvalidAlgorithmParameterException の代わりに IllegalArgumentException をスローするようになった。 caName パラメータの指定が正しくないときに IllegalArgumentException をスローするようになった
PolicyQualifierInfo クラスが final クラスになった
getTrustedCert、getCAName、getCAPublicKey、getNameConstraints の各メソッドが TrustAnchor の final メソッドになった
PolicyNode の isImmutable メソッドが削除され、すべてのインスタンスに不変であることが要求されるようになった
policyTree パラメータが不変でない場合に PKIXCertPathValidatorResult および PKIXCertPathBuilderResult のコンストラクタが InvalidParameterException をスローしなくなった (現在では PolicyNode のインスタンスはすべて不変)
PKIXBuilderParameters の setMaxPathLength メソッドの仕様が変更され、PKIX 証明書プロファイル (http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-08.txt) 準拠になった。このメソッドは、maxPathLength パラメータに範囲外の値が指定された場合、InvalidParameterException (RuntimeException) をスローするようになった
X.509 CertPath に TrustAnchor 証明書を組み込むことができなくなった
X.509 CertPath の新しい標準符号化形式 PkiPath が追加された。

概要

Java^TM Certification Path API は、証明書パス (「証明連鎖」とも呼ばれる) を扱うためのクラスとインタフェースで構成されます。証明書パスは、順序付けされた証明書リストです。証明書パスは、特定の検証規則を満たす場合に、公開鍵から主体へのマッピングを安全に確立するために使用されます。

この API は、証明書パスの作成、構築、検証用のインタフェースおよび抽象クラスを定義します。実装をプラグインする際は、プロバイダベースのインタフェースを使用できます。 API は、「Java 暗号化アーキテクチャドキュメント」で説明されている暗号化サービスプロバイダアーキテクチャに基づいています。

また、API には、PKIX 標準に従って X 509 証明書パスを構築および検証するためのアルゴリズム特定型のクラスが含まれます。 PKIX 標準は、IETF PKIX ワーキンググループによって開発されます。

この API は、Java^TM 2 SDK, Standard Edition (J2SDK), v 1.4 に含まれており、現在 Java Community Process^SM プログラムにより審議中です (Java^TM Specification Request (JSR) 000055)。 JSR および最新のステータスについての情報は、JSR 055 ホームページを参照してください。

謝辞
Certification Path API の開発に携わった方々、および有用なコメントや技術的なアドバイスをくださった方々に感謝いたします。 Certification Path API を設計および開発し、Java Community Process に準拠した作業基準を定めた Sun Microsystems Laboratories チームのメンバには、心からの感謝を捧げます。このチームのメンバは、Anne Anderson、Yassir Elley、Geoff Goodell、Steve Hanna、Sean Mullan、Radia Perlman、および Seth Proctor の各氏です。
エキスパートグループは、Java Community Process を使って API を改良し、調整を施す作業の一翼を担いました。このグループのメンバは、以下の方々です。

Peter Hesse、CygnaCom Solutions、An Entrust Technologies
Sean Mullan、Sun Microsystems (仕様リード)
Anthony Nadalin、IBM
Bob Naugle、Bluestone Software
Hemma Prafullchandra、Verisign
Ming Yung、DSTC
Sun Microsystems の Maxine Erlund、Steve Hanna、Phil Rosenzweig および Bob Sproull の各氏には、指導と洞察を提供していただきました。 Sun Microsystems の Java Security, Networking and Naming Group のメンバ (特にSharon Liu、Jeff Nisewanger、Gary Ellison、および Andreas Sterbenz の各氏) には、貴重なコメントやサポートをいただきました。その他、貴重なコメントやアドバイスを多くの技術メンバ (特に Mary Dageforde、Edward Dobner、Tom Gindin、Jan Luehe、David Kuehr-McLaren、Parag Salvi、Alexei Semidetnov、および Yanni Zhang の各氏) からいただきました。
このドキュメントの対象読者
このドキュメントは、次の 2 つの条件のいずれかに該当する、経験ある開発者を対象にしています。

証明書パスを構築または検証する、セキュリティ保護されたアプリケーションを設計する人
証明書パスを構築または検証するためのサービスプロバイダ実装を記述する人

関連ドキュメント
このドキュメントは、読者が http://java.sun.com/j2se/1.4/ja/docs/ja/guide/security/index.html からオンラインで入手できる次のドキュメントをすでに読んでいることを前提としています。

X.509 証明書と証明書の取り消しリスト (CRL)

Java 暗号化アーキテクチャ

Java 暗号化アーキテクチャ用プロバイダの実装方法

はじめに

公開鍵アプリケーションおよびシステムのユーザは、主体の公開鍵が本物であること、つまり、関連する非公開鍵が主体によって所有されていることを確信している必要があります。公開鍵証明書は、この信頼を確立するのに使用されます。 公開鍵 (またはアイデンティティ) 証明書 は、公開鍵のアイデンティティへのバインディングです。アイデンティティは、別のエンティティ (多くの場合証明書発行局 (CA) と呼ばれる) の非公開鍵でデジタル署名されます。この項の残りの部分では、CA という用語は、証明書に署名するエンティティの意味で使用されます。

ユーザは、主体の公開鍵証明書に署名した CA の公開鍵の信頼できるコピーを持っていない場合、署名している CA を保証する別の公開鍵証明書が必要です。この論理は、証明書の連鎖 (または証明書パス) が信頼できるアンカーまたは最も信頼できる CA から検出されるまで、再帰的にターゲットの主体 (一般にエンドエンティティと呼ばれる) に適用されます。通常、最も信頼できる CA は、ユーザが直接信頼する CA に宛てて発行した証明書によって指定されます。一般に証明書パスは順序付けされた証明書のリストで、通常の場合、エンドエンティティの公開鍵証明書と 0 個以上の付加的な証明書で構成されます。通常、証明書パスには 1 つ以上の符号化があります。これにより、証明書パスは、安全にネットワークを通じて伝送されたり、別のオペレーティングシステムアーキテクチャへ送信されたりします。

図 1 は、最も信頼できる CA の公開鍵 (CA 1) からターゲットの主体 (Alice) への証明書パスを示しています。証明書パスは、CA 2 という名前の中間 CA を介して、Alice の公開鍵との信頼を確立します。

図 1: 証明書パス

証明書パスは、主体の公開鍵の信頼を確立するため、信頼する前に検証する必要があります。検証では、署名を検証したり、各証明書が取り消されていないことを確認したりするなど、証明書パスに含まれている証明書に対するさまざまなチェックを行います。 PKIX 標準は、X.509 証明書で構成される証明書パスの検証に関するアルゴリズムを定義します。

ユーザは、最も信頼できる CA から主体への証明書パスを持っていないことがあります。証明書パスを構築または検出するサービスの提供は、公開鍵に対応するシステムの重要な機能です。 RFC 2587 は、LDAP (Lightweight Directory Access Protocol) スキーマ定義を定義します。LDAP スキーマ定義により、LDAP ディレクトリサービスプロトコルを使った X.509 証明書パスの検出が容易になります。

証明書パスの構築および検証は、SSL/TLS、S/MIME、IPSEC など、多くの標準セキュリティプロトコルの重要な一部です。 Java^TM Certification Path API は、この機能をアプリケーションに統合する必要のある開発者に、クラスおよびインタフェースのセットを提供します。この API は、特定の証明書パスの構築、または検証アルゴリズム用にサービスプロバイダ実装を記述する必要がある開発者、および実装に依存しない方式による証明書パスの作成、構築、および検証のために標準アルゴリズムにアクセスする必要のある開発者にとって便利です。

コアクラスとインタフェース

Java Certification Path API のコアクラスは、アルゴリズムおよび実装に依存しない方式の証明書パスの機能をサポートするインタフェースおよびクラスで構成されています。また、API には、PKIX 標準に準拠した、アルゴリズムに依存しないクラスのセットが含まれています。PKIX 標準については、「PKIX クラス」セクションで説明します。 API は、証明書を処理する既存の Java^TM 2 SDK, Standard Edition (J2SDK) java.security.cert パッケージに構築され、その機能を拡張します。コアクラスは、次のように基本、検証、構築、およびストレージという 4 つのクラスカテゴリに分けることができます。

基本の Certification Path クラス
- CertPath、CertificateFactory、CertPathParameters
Certification Path 検証クラス
- CertPathValidator、CertPathValidatorResult
Certification Path 構築クラス
- CertPathBuilder、CertPathBuilderResult
証明書/CRL ストレージクラス
- CertStore、CertStoreParameters、CertSelector、CRLSelector

次のセクションでは、各クラスおよびインタフェースの最も一般的に使用されているメソッドを説明します。いくつかのクラスの使用例は、このガイド全体を通じて、何度か出てきます。 Certification Path API クラスの完全なリファレンスドキュメントは、次のとおりです。

java.security.cert パッケージの概要

CertPath API のクラスおよびインタフェースの大半は、スレッドに対して安全ではありません。しかし、このガイドおよび API 仕様で言及された例外もあります。スレッドに対して安全でない単一のオブジェクトに同時にアクセスする必要のある複数のスレッドは、互いに同期して必要なロックを行うものとします。複数のスレッドがそれぞれ個別のオブジェクトを処理する場合、それらのスレッドは同期する必要はありません。

基本の証明書パスクラス

基本の証明書パスクラスは、証明書パスを符号化および表示する基本的な機能を提供します。 Java Certification Path API の主要な基本クラスは CertPath です。このクラスは、すべての型の証明書パスで共有される汎用的な部分をカプセル化します。アプリケーションは、CertificateFactory クラスのインスタンスを使って CertPath オブジェクトを作成します。

CertPath クラス

CertPath クラスは、証明書パスの抽象クラスです。すべての証明書パスオブジェクトが共有する機能を定義します。さまざまな証明書パスの型は、それが異なる内容および順序付けスキーマを持っていても、CertPath クラスをサブクラス化することによって実装できます。すべての CertPath オブジェクトは、直列化可能、不変、かつスレッドに対して安全です。さらに、次の特徴を備えています。

A 型

これは、証明書パスの証明書の型と対応しています。たとえば、X.509 がこれに該当します。 CertPath の型は、次のメソッドを使って取得されます。
```
    public String getType()
```
標準的な証明書の型の詳細については、「Java 暗号化アーキテクチャ API の仕様およびリファレンス」の「付録 A」を参照してください。
証明書リスト

getCertificates メソッドは、証明書パスに含まれる証明書のリストを返します。
```
    public abstract List getCertificates()
```
このメソッドは、0 個以上の java.security.cert.Certificate オブジェクトの List を返します。返される List およびその中に含まれる Certificates は、CertPath オブジェクトの内容を保護するため、変更できません。
返される証明書の順序付けは、型に依存します。規則により、X.509 型の CertPath オブジェクト内の証明書は、ターゲットとなる証明書から順に並べられ、信頼できるアンカーによって発行された証明書が最後に置かれます。つまり、証明書の発行者は、その次に続く証明書の主体になります。 TrustAnchor を表す証明書を証明書パスに含めることはできません。ただし、検証されていない X.509 の CertPath は、この規則に従っていないことがあります。 PKIX CertPathValidator は、この規則の違反を検出することにより、証明書パスが無効になり CertPathValidatorException がスローされるのを防ぎます。
1 つ以上の符号化

各 CertPath オブジェクトは、1 つ以上の符号化をサポートします。これらは証明書パスの外部符号化形式で、ネットワークを通じてパスを別の組織に転送する際に、パスの標準表示が Java 仮想マシンの外部で必要なときに使用します。各パスはデフォルトの形式で符号化され、そのバイトは次のメソッドを使って返されます。
```
    public abstract byte[] getEncoded()
```
一方、getEncoded(String) メソッドは、符号化形式を String (例: 「PKCS7」) と指定することにより、サポートされる特定の符号化を返します。標準の符号化形式のリストは、付録 A で定義されています。
```
    public abstract byte[] getEncoded(Sting encoding)
```
また、getEncodings メソッドは、サポートされる符号化形式 String でも反復子を返します (デフォルトの符号化形式が最初に返される)。
```
    public abstract Iterator getEncodings()
```

すべての CertPath オブジェクトはまた、Serializable です。 CertPath オブジェクトは、直列化中に、代替の CertPathRep オブジェクトに解釈処理されます。これにより、基本的な実装にかかわらず、CertPath オブジェクトを同等の表現に直列化できます。

CertPath オブジェクトは、CertificateFactory を使って、符号化されたバイト配列または Certificate のリストから生成されます。一方、CertPathBuilder は、最も信頼できる CA から特定の主体への CertPath を探すために使用されます。 CertPath オブジェクトが作成されると、それは CertPathValidator の validate メソッドに渡され、検証されます。これらの概念の詳細については、続くセクションで説明します。

CertificateFactory クラス

CertificateFactory クラスは、証明書ファクトリの機能を定義するエンジンクラスです。このクラスは、J2SDK, v 1.4 より前のリリースでは、Certificate および CRL オブジェクトの生成に使用されていました。 J2SDK, v1.4 では、クラスが拡張され、証明書パス (CertPath) オブジェクトの生成にも使用されるようになりました。 CertificateFactory を CertPathBuilder と混同しないでください。 CertPathBuilder (後述) は、証明書パスが存在しないときに、証明書パスの検出または発見に使用されます。それに対して CertificateFactory は、証明書パスがすでに検出されていて、符号化されたバイト配列または Certificate の配列など、異なる形式で存在する内容から呼び出し側が CertPath オブジェクトのインスタンスを生成する必要があるときに使用されます。

CertificateFactory オブジェクトの作成

CertificateFactory オブジェクトの作成に関する詳細については、「Java 暗号化アーキテクチャ」の「CertificateFactory」セクションを参照してください。

CertPath オブジェクトの生成

CertificateFactory のインスタンスは、Certificate オブジェクトのリスト、または CertPath の符号化された形式を含む InputStream から、 CertPath オブジェクトを生成します。 CertPath と同様、それぞれの CertificateFactory は、証明書パス (PKCS#7 など) のデフォルトの符号化形式をサポートします。 CertPath オブジェクトを生成し、そのオブジェクトを入力ストリームから (デフォルトの符号化形式で) 読み込まれたデータを使って初期化するには、generateCertPath メソッドを使用します。
    public final CertPath generateCertPath(InputStream inStream)
特定の符号化形式から読み込まれたデータを使用する場合は次のようになります。
    public final CertPath generateCertPath(InputStream inStream,
    					   String encoding)
サポートされている符号化形式を調べるには、getCertPathEncodings メソッドを使用します (デフォルトの符号化が最初に返される)。
    public final Iterator getCertPathEncodings()
証明書パスオブジェクトを Certificate オブジェクトのリストから生成するには、次のメソッドを使用します。
    public final CertPath generateCertPath(List certificates)
CertificateFactory は、ファクトリと同じ型の Certificate で構成された CertPath オブジェクトを常に返します。たとえば、X.509 型の CertificateFactory は、java.security.cert.X509Certificate のインスタンスである証明書で構成された CertPath オブジェクトを返します。

次のコード例は、PKCS#7 で符号化された、ファイルに格納されている証明書応答から証明書パスを生成する方法を示しています。
    // open an input stream to the file
    FileInputStream fis = new FileInputStream(filename);
    // instantiate a CertificateFactory for X.509
    CertificateFactory cf = CertificateFactory.getInstance("X.509");
    // extract the certification path from
    // the PKCS7 SignedData structure
    CertPath cp = cf.generateCertPath(fis, "PKCS7");
    // print each certificate in the path
    List certs = cp.getCertificates();
    Iterator i = certs.iterator();
    while (i.hasNext()) {
        X509Certificate cert = (X509Certificate) i.next();
        System.out.println(cert);
    }
	
次に、KeyStore から証明連鎖をフェッチして、CertificateFactory を使って CertPath に変換する別のコード例を示します。
    // instantiate a KeyStore with type JKS
    KeyStore ks = KeyStore.getInstance("JKS");
    // load the contents of the KeyStore
    ks.load(new FileInputStream("./keystore"),
    	"password".toCharArray());
    // fetch certificate chain stored with alias "sean"
    Certificate[] certArray = ks.getCertificateChain("sean");
    // convert chain to a List
    List certList = Arrays.asList(certArray);
    // instantiate a CertificateFactory for X.509
    CertificateFactory cf = CertificateFactory.getInstance("X.509");
    // extract the certification path from
    // the List of Certificates
    CertPath cp = cf.generateCertPath(certList);
	

generateCertificates という名前の CertificateFactory に、Certificate のシーケンスを構文解析する既存のメソッドがあることに注目してください。複数の証明書からなる符号化では、互いに関連性がないと思われる証明書のコレクションを解析する場合に、generateCertificates を使用します。それ以外の符号化では、CertPath を生成し、CertPathValidator (後述) で検証する場合に、generateCertPath を使用します。

CertPathParameters インタフェース

CertPathParameters インタフェースは、特定の証明書パスビルダまたは検証アルゴリズムで使用される一連のパラメータの透明な表現です。このインタフェースの主な目的は、すべての証明書パスのパラメータの仕様をグループ化すること (およびそれらのパラメータに安全な型を提供すること) です。 CertPathParameters インタフェースは、Cloneable インタフェースを拡張し、例外をスローしない clone() メソッドを定義します。このインタフェースのすべての固定実装は、必要に応じて Object.clone() メソッドを実装し、オーバーライドします。これにより、アプリケーションは、CertPathParameters オブジェクトを複製できます。

CertPathParameters インタフェースを実装しているオブジェクトは、CertPathValidator および CertPathBuilder クラスのメソッドに引数として渡されます。一般に、CertPathParameters インタフェースの固定実装は、特定の証明書パスの構築または検証アルゴリズムに固有の入力パラメータのセットを保持します。たとえば、PKIXParameters クラスは、PKIX 証明書パス検証アルゴリズムの入力パラメータのセットを保持する CertPathParameters インタフェースの実装です。このようなパラメータの 1 つに、呼び出し側が検証処理のアンカーについて信頼する、最も信頼できる CA のセットがあります。このパラメータについては特に、PKIXParameters クラスを扱ったセクションで詳しく説明します。

Certification Path 検証クラス

Java Certification Path API には、証明書パスを検証するクラスおよびインタフェースが含まれています。アプリケーションは、CertPathValidator クラスのインスタンスを使って、CertPath オブジェクトを検証します。成功すると、CertPathValidatorResult インタフェースを実装するオブジェクトに、検証アルゴリズムの結果が返されます。

CertPathValidator クラス

CertPathValidator クラスは、証明書パスの検証に使用されるエンジンクラスです。

CertPathValidator オブジェクトの生成

ほかのエンジンクラスと同様に、特定の検証アルゴリズム用の CertPathValidator オブジェクトを取得するには、CertPathValidator クラスの getInstance static ファクトリメソッドの 1 つを呼び出します。
	public static CertPathValidator getInstance(String algorithm)
    	public static CertPathValidator getInstance(String algorithm,
						    String provider)
    	public static CertPathValidator getInstance(String algorithm,
						    Provider provider)
algorithm パラメータは、証明書パス検証アルゴリズム (「PKIX」など) の名前です。標準の CertPathValidator アルゴリズム名は、付録 A のリストに記載されています。
証明書パスの検証

CertPathValidator オブジェクトが生成されると、validate メソッドを呼び出して、検証する証明書パスおよびアルゴリズム特定型のパラメータセットを渡すことによって、パスを検証できます。
	public final CertPathValidatorResult
	    	validate(CertPath certPath, CertPathParameters params)
		throws CertPathValidatorException,
		       InvalidAlgorithmParameterException
検証アルゴリズムが成功すると、CertPathValidatorResult インタフェースを実装するオブジェクトに結果が返されます。そうでない場合は、CertPathValidatorException がスローされます。 CertPathValidatorException には、CertPath を返すメソッドが含まれます。また、必要に応じて、アルゴリズムの失敗を引き起こした証明書のインデックスや、エラーの根本となる例外または原因を返すメソッドが含まれます。

validate メソッドに渡される CertPath および CertPathParameters は、検証アルゴリズムによってサポートされた型である必要があります。そうでない場合は、InvalidAlgorithmParameterException がスローされます。たとえば、PKIX アルゴリズムを実装する CertPathValidator インスタンスは、X.509 型の CertPath オブジェクト、および PKIXParameters のインスタンスである CertPathParameters を検証します。

CertPathValidatorResult インタフェース

CertPathValidatorResult インタフェースは、証明書パス検証アルゴリズムの成功結果または出力の透明な表現です。このインタフェースの主な目的は、すべての検証結果をグループ化すること (およびそれらの検証結果に安全な型を提供すること) です。 CertPathParameters インタフェースと同様に、CertPathValidatorResult は Cloneable を拡張し、例外をスローしない clone() メソッドを定義します。これにより、アプリケーションは、CertPathValidatorResult オブジェクトを複製できます。

CertPathValidatorResult インタフェースを実装しているオブジェクトは、 CertPathValidator の validate メソッドによって返されます (成功時のみ。そうでない場合は、CertPathValidatorException はエラーの記述とともにスローされます)。一般に、CertPathValidatorResult インタフェースの固定実装は、特定の証明書パスの検証アルゴリズムに固有の出力パラメータのセットを保持します。たとえば、PKIXCertPathValidatorResult クラスは、PKIX 証明書パス検証アルゴリズムの出力パラメータのセットを取得するメソッドを含む CertPathValidatorResult インタフェースの実装です。このようなパラメータの 1 つに、有効なポリシーツリーがあります。このパラメータについては特に、PKIXCertPathValidatorResult クラスを扱ったセクションで詳しく説明します。

次の簡単なコード例では、CertPathValidator を作成し、証明書パスの検証に使用する方法を示します。この例は、validate メソッドに渡される CertPath および CertPathParameters オブジェクトが事前に作成されていることを前提としています。より詳しい例は、PKIX クラスを説明したセクションにあります。

    // create CertPathValidator that implements the "PKIX" algorithm
    CertPathValidator cpv = null;
    try {
        cpv = CertPathValidator.getInstance("PKIX");
    } catch (NoSuchAlgorithmException nsae) {
	System.err.println(nsae);
	System.exit(1);
    }
    // validate certification path ("cp") with specified parameters ("params")
    try {
        CertPathValidatorResult cpvResult = cpv.validate(cp, params);
    } catch (InvalidAlgorithmParameterException iape) {
	System.err.println("validation failed: " + iape);
	System.exit(1);
    } catch (CertPathValidatorException cpve) {
	System.err.println("validation failed: " + cpve);
	System.err.println("index of certificate that caused exception: "
		+ cpve.getIndex());
	System.exit(1);
    }

Certification Path 構築クラス

Java Certification Path API には、証明書パスを構築する (または検出する) ためのクラスが含まれています。アプリケーションは、CertPathBuilder クラスのインスタンスを使って、CertPath オブジェクトを構築します。成功すると、CertPathBuilderResult インタフェースを実装するオブジェクトに、構築の結果が返されます。

CertPathBuilder クラス

CertPathBuilder クラスは、証明書パスの構築に使用されるエンジンクラスです。

CertPathBuilder オブジェクトの生成

ほかのエンジンクラスと同様に、特定の構築アルゴリズム用の CertPathBuilder オブジェクトを取得するには、CertPathBuilder クラスの getInstance static ファクトリメソッドを呼び出します。
	public static CertPathBuilder getInstance(String algorithm)
	public static CertPathBuilder getInstance(String algorithm,
						  String provider)
    	public static CertPathBuilder getInstance(String algorithm,
					          Provider provider)
algorithm パラメータは、証明書パス構築アルゴリズム (「PKIX」など) の名前です。標準の CertPathBuilder アルゴリズム名は、付録 A のリストに記載されています。
証明書パスの構築

CertPathBuilder オブジェクトが作成されると、build メソッドを呼び出して、アルゴリズム特定型のパラメータ仕様を渡すことによって、パスを構築できます。
	public final CertPathBuilderResult build(CertPathParameters params)
		throws CertPathBuilderException,
		       InvalidAlgorithmParameterException
構築アルゴリズムが成功すると、CertPathBuilderResult インタフェースを実装するオブジェクトに結果が返されます。失敗した場合は、たとえば、基になる例外 (存在する場合) とエラーメッセージなど、エラーについての情報を含む CertPathBuilderException がスローされます。

build メソッドに渡される CertPathParameters は、構築アルゴリズムによってサポートされた型である必要があります。そうでない場合は、InvalidAlgorithmParameterException がスローされます。

CertPathBuilderResult インタフェース

CertPathBuilderResult インタフェースは、証明書パス構築アルゴリズムの結果または出力の透明な表現です。このインタフェースには、次に示すように、正常に構築された証明書パスを返すメソッドが含まれます。

	public CertPath getCertPath()

CertPathBuilderResult インタフェースの目的は、すべての構築結果をグループ化すること (およびそれらの構築結果に安全な型を提供すること) です。 CertPathValidatorResult インタフェースと同様に、CertPathBuilderResult は Cloneable を拡張し、例外をスローしない clone() メソッドを定義します。これにより、アプリケーションは、CertPathBuilderResult オブジェクトを複製できます。

CertPathBuilderResult インタフェースを実装するオブジェクトは、CertPathBuilder の build メソッドによって返されます。

次の簡単なコード例では、CertPathBuilder を作成して、証明書パスの構築に使用する方法を示します。この例は、build メソッドに渡される CertPathParameters オブジェクトが事前に作成されていることを前提としています。より詳しい例は、PKIX クラスを説明したセクションにあります。

    // create CertPathBuilder that implements the "PKIX" algorithm
    CertPathBuilder cpb = null;
    try {
        cpb = CertPathBuilder.getInstance("PKIX");
    } catch (NoSuchAlgorithmException nsae) {
	System.err.println(nsae);
	System.exit(1);
    }
    // build certification path using specified parameters ("params")
    try {
        CertPathBuilderResult cpbResult = cpb.build(params);
        CertPath cp = cpbResult.getCertPath();
        System.out.println("build passed, path contents: " + cp);
    } catch (InvalidAlgorithmParameterException iape) {
	System.err.println("build failed: " + iape);
	System.exit(1);
    } catch (CertPathBuilderException cpbe) {
	System.err.println("build failed: " + cpbe);
	System.exit(1);
    }

証明書/CRL ストレージクラス

Java Certification Path API には、リポジトリから証明書および CRL を取得する CertStore クラスも含まれています。このクラスを使用すると、呼び出し側は、CertPathValidator または CertPathBuilder の実装が証明書および CRL の検出に使用するリポジトリを指定できます (例については、PKIXParameters のaddCertStores メソッドを参照)。

CertPathValidator 実装は、呼び出し側がコールバック機構として指定した CertStore オブジェクトを使用して CRL をフェッチし、取り消しのチェックを行います。同様に、CertPathBuilder 実装は、CertStore をコールバック機構として使用して証明書をフェッチします。また、取り消しのチェックを行っている場合は CRL をフェッチします。

CertStore クラス

CertStore クラスは、証明書および証明書の取り消しリスト (CRL) のリポジトリとして機能するエンジンクラスです。このクラスは、CertPathBuilder および CertPathValidator の実装によって、証明書および CRL の検索のため、または汎用の証明書および CRL の取得機構として使用されます。

CertStore は、非公開鍵および信頼できる証明書のキャッシュへのアクセスを提供する java.security.KeyStore クラスとは異なり、非常に大きくなる可能性がある、信頼されない証明書および CRL のリポジトリへのアクセスを提供するように設計されています。たとえば、CertStore の LDAP 実装は、1 つ以上のディレクトリに格納されている証明書または CRL に対するアクセスを、LDAP プロトコルを使って提供します。

CertStore オブジェクトのすべての public メソッドは、スレッドに対して安全です。つまり、単一の (または複数の) CertStore オブジェクト上で、複数のスレッドがこれらのメソッドを同時に呼び出しても、悪影響はありません。これにより、たとえば CertPathBuilder は、CRL を検索しながら、同時に他の証明書を検索することができます。

CertStore オブジェクトの生成

ほかのエンジンクラスと同様に、特定のリポジトリ型用の CertStore オブジェクトを取得するには、CertStore クラスで以下の getInstance static ファクトリメソッドのどれかを呼び出します。
	public static CertStore getInstance(String type,
		CertStoreParameters params)
	public static CertStore getInstance(String type,
		CertStoreParameters params, String provider)
	public static CertStore getInstance(String type,
		CertStoreParameters params, Provider provider)
type パラメータは、証明書リポジトリ型 (「LDAP」など) の名前です。標準の CertStore 型は、付録 A のリストに記載されています。
初期化パラメータ (params) は、リポジトリ型に固有のものです。たとえば、サーバベースのリポジトリの初期化パラメータは、サーバのホスト名およびポートを含みます。パラメータがこの CertStore 型について無効な場合、InvalidAlgorithmParameterException がスローされます。 getCertStoreParameters メソッドは、CertStore の初期化に使用された CertStoreParameters を返します。
	public final CertStoreParameters getCertStoreParameters()
証明書の取得

CertStore オブジェクトを生成すると、getCertificates メソッドを使ってリポジトリから証明書を取得できます。このメソッドは、CertSelector オブジェクト (詳細は後述) を引数として取得します。この引数は、どの証明書が返されるかを決定する一連の選択条件を指定します。
	public final Collection getCertificates(CertSelector selector)
		throws CertStoreException
このメソッドは、選択条件を満たす java.security.cert.Certificate オブジェクトの Collection を返します。条件が満たすものがない場合は、空の Collection が返されます。リモートリポジトリとの通信障害など、予期しないエラー状態が生じた場合は、通常、CertStoreException がスローされます。

ある種の CertStore 実装では、指定した選択条件を満たす証明書または CRL をリポジトリ全体で検索できません。これらのインスタンスでは、CertStore 実装は、証明書および CRL を検索するセレクタで指定された情報を使用します。たとえば、LDAP CertStore は、ディレクトリ内のすべてのエントリを検索しない場合があります。その代わりに、探している証明書を含んでいる可能性のあるエントリだけを検索します。 LDAP CertStore がどのエントリを検索すべきかを判断するための十分な情報を CertSelector が提供しない場合、LDAP CertStore は CertStoreException をスローします。

CRL の取得

getCRLs メソッドを使ってリポジトリから CRL を取得することもできます。このメソッドは、CRLSelector オブジェクト (詳細は後述) を引数として取得します。この引数は、どの CRL が返されるかを決定する一連の選択条件を指定します。
	public final Collection getCRLs(CRLSelector selector)
		throws CertStoreException
このメソッドは、選択条件を満たす java.security.cert.CRL オブジェクトの Collection を返します。条件が満たすものがない場合は、空の Collection が返されます。

CertStoreParameters インタフェース

CertStoreParameters インタフェースは、特定の CertStore で使用されるパラメータのセットの透明な表現です。このインタフェースの主な目的は、すべての証明書ストレージのパラメータの仕様をグループ化すること (およびそれらのパラメータに安全な型を提供すること) です。 CertStoreParameters インタフェースは、Cloneable インタフェースを拡張し、例外をスローしない clone メソッドを定義します。このインタフェースの実装は、必要に応じて Object.clone() メソッドを実装し、オーバーライドします。これにより、アプリケーションは、CertStoreParameters オブジェクトを複製できます。

CertStoreParameters インタフェースを実装しているオブジェクトは、CertStore クラスの getInstance メソッドに引数として渡されます。 CertStoreParameters インタフェースを実装している次の 2 つのクラスは、この API で定義されます。 LDAPCertStoreParameters および CollectionCertStoreParameters クラス。

LDAPCertStoreParameters クラス

LDAPCertStoreParameters クラスは、CertStoreParameters インタフェースの実装で、証明書および CRL を LDAP 型の CertStore から取得するために最低限の初期化パラメータのセット (ディレクトリサーバのホストおよびポート番号) を保持します。

このクラスの詳細については、LDAPCertStoreParameters のAPI ドキュメントを参照してください。

CollectionCertStoreParameters クラス

CollectionCertStoreParameters クラスは、CertStoreParameters インタフェースの実装で、証明書および CRL を Collection 型の CertStore から取得するための初期化パラメータのセットを保持します。

このクラスの詳細については、CollectionCertStoreParameters の API ドキュメントを参照してください。

CertSelector および CRLSelector インタフェース

CertSelector および CRLSelector インタフェースは、証明書および CRL のコレクションまたは大きなグループから、証明書および CRL を選択するための一連の条件の仕様です。インタフェースはグループ化され、すべてのセレクタの仕様に型の安全性を提供します。各セレクタインタフェースは、Cloneable を拡張し、例外をスローしない clone() メソッドを定義します。これにより、アプリケーションは、どの CertSelector または CRLSelector オブジェクトも複製できます。

CertSelector および CRLSelector インタフェースは、それぞれ match という名前のメソッドを定義します。 match メソッドは、Certificate または CRL オブジェクトを引数として取得し、オブジェクトが選択条件を満たす場合、true を返します。そうでない場合は、false を返します。 CertSelector インタフェースの match メソッドは、次のようにして定義されます。

	public boolean match(Certificate cert)

CRLSelector インタフェースについては、次のようにして定義されます。

	public boolean match(CRL crl)

一般に、これらのインタフェースを実装しているオブジェクトは、CertStore クラスの getCertificates および getCRLs メソッドにパラメータとして渡されます。これらのメソッドは、指定された選択条件を満たす CertStore リポジトリから、Certificate または CRL の Collection を返します。また、CertSelector は、証明書パスのターゲットまたはエンドエンティティ証明書で、検証の制約を指定するためにも使用されます (PKIXParameters.setTargetCertConstraints メソッドの例を参照)。

X509CertSelector クラス

X509CertSelector クラスは、X.509 証明書を選択するための一連の条件を定義する CertSelector インタフェースの実装です。 X509Certificate オブジェクトは、match メソッドによって選択されるには、指定された条件のすべてを満たす必要があります。この選択条件は、CertPathBuilder 実装が X.509 証明書パスを構築する際に、潜在的な証明書を検出するために使用するよう設計されています。

たとえば、X509CertSelector の setSubject メソッドを使用すると、PKIX CertPathBuilder は、部分的に完成された連鎖の中で、先行する X509Certificate の発行者名と一致しない X509Certificate をフィルタにかけることができます。 X509CertSelector オブジェクトで、この条件とともにその他の条件を設定することにより、CertPathBuilder は、無関係な証明書を破棄して、CertPathParameters オブジェクトで指定した要件を満たす X.509 証明書パスをより簡単に探すことができます。

ここで説明した X.509 証明書の拡張機能の定義については、 http://www.ietf.org/rfc/rfc2459.txt を参照してください。

X509CertSelector オブジェクトの生成

X509CertSelector オブジェクトは、次のようにしてデフォルトのコンストラクタを呼び出すことにより生成されます。
	public X509CertSelector()
最初は、条件は何も設定されていません (どの X509Certificate も一致)。

選択条件の設定

呼び出し側は、選択条件を使用して X.509 証明書の異なるコンポーネントを照合することができます。ここでは、選択条件を設定するいくつかのメソッドについて説明します。その他のメソッドの詳細については、X509CertSelector の API ドキュメントを参照してください。

setIssuer メソッドは、発行者の条件を設定します。
	public void setIssuer(String issuerDN)
	public void setIssuer(byte[] issuerDN)
指定された識別名 (RFC 2253 String または ASN.1 DER 符号化形式) は、証明書にある発行者の識別名と必ず一致する必要があります。 null の場合、発行者の識別名は問われません。

同様に、setSubject メソッドは主体の条件を設定します。
	public void setSubject(String subjectDN)
	public void setSubject(byte[] subjectDN)
指定された識別名 (RFC 2253 String または ASN.1 DER 符号化形式) は、証明書にある主体の識別名と必ず一致する必要があります。 null の場合、主体の識別名は問われません。
setSerialNumber メソッドは、serialNumber の条件を設定します。
	public void setSerialNumber(BigInteger serial)
指定されたシリアル番号は、証明書にある証明書シリアル番号と必ず一致する必要があります。 null の場合、証明書シリアル番号は問われません。

setAuthorityKeyIdentifier メソッドは、authorityKeyIdentifier の条件を設定します。
	public void setAuthorityKeyIdentifier(byte[] authorityKeyID)
証明書には、指定された値と一致する Authority Key Identifier 拡張機能が含まれている必要があります。 null の場合、authorityKeyIdentifier 条件に関する確認は行われません。

setCertificateValid メソッドは、certificateValid の条件を設定します。
	public void setCertificateValid(Date certValid)
指定された日付は、証明書の証明書有効期間内に収まる必要があります。 null の場合、どの日付も有効です。

setKeyUsage メソッドは、keyUsage の条件を設定します。
	public void setKeyUsage(boolean[] keyUsage)
証明書の Key Usage Extension は、指定された KeyUsage の値 (true に設定されている値) を許可する必要があります。 null の場合、keyUsage の確認は行われません。

選択条件の取得

各選択条件の現在の値は、該当する get メソッドを使って取得できます。これらのメソッドについての詳細は、X509CertSelector の API ドキュメントを参照してください。

例

ここでは、X509CertSelector クラスを使って LDAP CertStore から X.509 証明書を取得する例を取り上げます。

はじめに、LDAP サーバのホスト名およびポートを含む CertStore オブジェクトの初期化に使用する LDAPCertStoreParameters オブジェクトを生成します。
	LDAPCertStoreParameters lcsp = new
		LDAPCertStoreParameters("ldap.sun.com", 389);
次に、CertStore オブジェクトを生成し、次の文のようにして、LDAPCertStoreParameters オブジェクトを渡します。
	CertStore cs = CertStore.getInstance("LDAP", lcsp);
この呼び出しは、RFC 2587 で定義されたスキーマを使って、証明書および CRL を LDAP リポジトリから取得する CertStore オブジェクトを生成します。

次のコードのブロックは、有効期限内のエンドエンティティの証明書をすべて取得する X509CertSelector を確立します。この証明書は、1) デジタル署名を許可する鍵の利用法、および 2) 特定の電子メールアドレスとともに主体の代替名を持つ特定の主体に発行されます。
	X509CertSelector xcs = new X509CertSelector();
	// select only unexpired certificates
	xcs.setCertificateValid(new Date());
	// select only certificates issued to
	// 'CN=alice, O=xyz, C=us'
	xcs.setSubject("CN=alice, O=xyz, C=us");
	// select only end-entity certificates
	xcs.setBasicConstraints(-2);
	// select only certificates with a digitalSignature
	// keyUsage bit set (set the first entry in the
	// boolean array to true)
	boolean[] keyUsage = {true};
	xcs.setKeyUsage(keyUsage);
	// select only certificates with a subjectAltName of
	// 'alice@xyz.com' (1 is the integer value of
	// an RFC822Name)
	xcs.addSubjectAlternativeName(1, "alice@xyz.com");
次に、以前に生成した CertStore オブジェクトの getCertificates メソッドにセレクタを渡します。
	Collection certs = cs.getCertificates(xcs);
PKIX CertPathBuilder は、潜在的な証明書の検出およびソートを容易にするため、同様のコードを使用して、検証制約またはその他の条件を満たさない潜在的な証明書を破棄することがあります。

X509CRLSelector クラス

X509CRLSelector クラスは、X.509 CRL を選択する一連の条件を定義する CRLSelector インタフェースの実装です。 X509CRL オブジェクトは、match メソッドによって選択されるには、指定された条件のすべてを満たす必要があります。選択条件は、リポジトリから CRL を取得する必要のある CertPathValidator または CertPathBuilder 実装が、X.509 証明書パスにある証明書の取り消し状況を確認するために役立つよう設計されています。

たとえば、X509CRLSelector の setDateAndTime メソッドを使用すると、PKIX CertPathValidator は、指示された時刻の後に発行された、または指示された時刻の前に期限が切れる X509CRL をフィルタにかけることができます。 X509CRLSelector オブジェクトで、この条件とともにその他の条件を設定することにより、CertPathValidator は、無関係な CRL を破棄して、証明書が取り消されているかどうかをより簡単にチェックすることができます。

ここで説明した X.509 CRL フィールドおよび拡張機能の定義については、http://www.ietf.org/rfc/rfc2459.txt を参照してください。

X509CRLSelector オブジェクトの生成

X509CRLSelector オブジェクトは、次のようにしてデフォルトのコンストラクタを呼び出すことにより生成されます。
	public X509CRLSelector()
最初、条件は何も設定されていません (どの X509CRL も一致)。

選択条件の設定

呼び出し側は、選択条件を使用して X.509 CRL の異なるコンポーネントを照合することができます。ここでは、選択条件を設定するほとんどのメソッドについて説明します。残りのメソッドの詳細については、X509CRLSelector の API ドキュメントを参照してください。

setIssuerNames メソッドは、issuerNames の条件を設定します。
	public void setIssuerNames(Collection names)
CRL にある発行者の識別名は、指定された識別名の少なくとも 1 つと一致する必要があります。 names 引数の各エントリは、String またはバイト配列 (それぞれ、RFC 2253 または ASN.1 DER 符号化形式の名前を表す) のどちらかです。 null の場合、発行者の識別名は問われません。

setMinCRLNumber および setMaxCRLNumber メソッドは、minCRLNumber および maxCRLN の条件を設定します。
	public void setMinCRLNumber(BigInteger minCRL)
	public void setMaxCRLNumber(BigInteger maxCRL)
CRL には、CRL Number 拡張機能が必要です。この拡張機能は、setMinCRLNumber メソッドが呼び出された場合に指定された値以上になり、setMaxCRLNumber メソッドが呼び出された場合に指定された値以下になる値を持ちます。これらのメソッドの 1 つに渡された値が null の場合、対応するチェックは行われません。

setDateAndTime メソッドは、dateAndTime の条件を設定します。
	public void setDateAndTime(Date dateAndTime)
指定された日付は、CRL の thisUpdate コンポーネントの値と同じか、またはそれより後で、さらに nextUpdate コンポーネントの値より前である必要があります。 null の場合、dateAndTime のチェックは行われません。

setCertificateChecking メソッドは、取り消し状況がチェックされている証明書を設定します。
	public void setCertificateChecking(X509Certificate cert)
これは、条件ではありません。特定の証明書の取り消しをチェックする際に、CertStore が関連する CRL を検索するのに役立つオプション情報です。 null が指定された場合、このようなオプション情報は提供されません。アプリケーションは、特定の証明書の取り消しをチェックする際、常にこのメソッドを呼び出し、CertStore が正しい CRL を検索して無関係な CRL をフィルタすることができるよう、より多くの情報を提供する必要があります。

選択条件の取得

各選択条件の現在の値は、該当する get メソッドを使って取得できます。これらのメソッドの詳細については、X509CRLSelector の API ドキュメントを参照してください。

例

CRL を LDAP リポジトリから取得する X509CRLSelector の生成方法は、X509CertSelector の例と同様です。特定の CA によって発行され、最小の CRL 番号を持つ、現在の (現在の日付および時刻) CRL すべてを取得すると仮定します。まず、X509CRLSelector オブジェクトを生成し、適当なメソッドを呼び出して選択条件を設定します。
	X509CRLSelector xcrls = new X509CRLSelector();
	// select CRLs satisfying current date and time
	xcrls.setDateAndTime(new Date());
	// select CRLs issued by 'O=xyz, C=us'
	xcrls.addIssuerName("O=xyz, C=us");
	// select only CRLs with a CRL number at least '2'
	xcrls.setMinCRLNumber(new BigInteger("2"));
次に、X509CertSelector の例で生成された CertStore オブジェクトの getCRLs メソッドにセレクタを渡します。
	Collection crls = cs.getCRLs(xcrls);

PKIX クラス

Java Certification Path API には、http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-08.txt で定義されている PKIX 証明書パス検証アルゴリズムで使用するためにモデル化された、アルゴリズム特定型のクラスのセットも含まれます。これは RFC 2459 に基づいた仕様の 9 番目のドラフトです。この仕様が完成すると、RFC 2459 は使用されなくなります。

TrustAnchor クラス

このクラスは、X.509 証明書パスの検証で信頼できるアンカーとして使用される「最も信頼できる CA」を表します。最も信頼できる CA には、CA の公開鍵、CA の名前、およびこの鍵を使って検証されるパスのセットに適用される制約が含まれます。これらのパラメータは、信頼できる X509Certificate の形式で、または個別のパラメータとして指定できます。
すべての TrustAnchor オブジェクトは、不変で、スレッドに対して安全です。つまり、単一の (または複数の) TrustAnchor オブジェクト上で、このクラスに定義されたメソッドを複数のスレッドが同時に呼び出しても、悪影響はありません。 TrustAnchor オブジェクトは、不変かつスレッドに対して安全でなければならないので、アクセスの調整を意識することなく、オブジェクトをさまざまなコードに渡すことができます。
このクラスは PKIX クラスとして説明されていますが、その他の X.509 証明書パスの検証アルゴリズムで使用されることもあります。
TrustAnchor オブジェクトの生成

TrustAnchor オブジェクトを初期化するには、呼び出し側は、信頼できる X509Certificate または公開鍵と識別名のペアとして、「最も信頼できる CA」を指定する必要があります。また、呼び出し側はオプションで、初期化の際に検証アルゴリズムが信頼できるアンカーに適用する名前の制約を指定することもできます。 PKIX アルゴリズムでは、信頼できるアンカーに適用する名前の制約をサポートする必要がないため、PKIX CertPathValidator または CertPathBuilder は、このパラメータをサポートすることなく例外をスローすることもできます。次の制約のうちの 1 つを使って、TrustAnchor オブジェクトを生成します。
	public TrustAnchor(X509Certificate trustedCert,
		byte[] nameConstraints)
	public TrustAnchor(String caName, PublicKey pubKey,
		byte[] nameConstraints)
nameConstraints パラメータは、NameConstraints 拡張機能の ASN.1 DER 符号化を含むバイト配列として指定されます。名前の制約が復号化できない (正しく書式設定されない) 場合、IllegalArgumentException がスローされます。
パラメータ値の取得

次のように、対応する get メソッドを使って、各パラメータを取得できます。
	public final X509Certificate getTrustedCert()
	public final String getCAName()
	public final PublicKey getCAPublicKey()
	public final byte[] getNameConstraints()
信頼できるアンカーが公開鍵と名前のペアとして指定されている場合、getTrustedCert メソッドは null を返します。同様に、信頼できるアンカーが X509Certificate として指定されている場合、getCAName および getCAPublicKey メソッドは null を返します。
PKIXParameters クラス

CertPathParameters インタフェースを実装するこのクラスは、PKIX 証明書パスの検証アルゴリズムにより定義された入力パラメータのセットを指定します。また、いくつかの有用な追加パラメータも含んでいます。

X.509 CertPath オブジェクトおよび PKIXParameters オブジェクトは、PKIX アルゴリズムを実装している CertPathValidator インスタンスの validate メソッドに引数として渡されます。 CertPathValidator は、パラメータを使って、PKIX 証明書パスの検証アルゴリズムを初期化します。
PKIXParameters オブジェクトの生成

PKIXParameters オブジェクトのインスタンスを生成するには、呼び出し側は、PKIX 検証アルゴリズムによる定義に従って「最も信頼できる CA」を指定する必要があります。最も信頼できる CA は、次のように、2 つのコンストラクタのうちの 1 つを使って指定できます。
	public PKIXParameters(Set trustAnchors)
	    throws InvalidAlgorithmParameterException
	public PKIXParameters(KeyStore keystore)
	    throws KeyStoreException, InvalidAlgorithmParameterException
最初のコンストラクタを使用すると、呼び出し側は、最も信頼できる CA を TrustAnchor オブジェクトのセットとして指定できます。代わりに、呼び出し側は 2 番目のコンストラクタを使って、信頼できる証明書のエントリを含む KeyStore インスタンスを指定できます。その各エントリは、最も信頼できる CA とみなされます。
パラメータ値の設定

PKIXParameters オブジェクトを作成すると、呼び出し側は、さまざまなパラメータを設定する (または現在の値を置き換える) ことができます。ここでは、パラメータを設定するためのいくつかのメソッドについて説明します。その他のメソッドの詳細については、PKIXParameters の API ドキュメントを参照してください。

setInitialPolicies メソッドは、PKIX 検証アルゴリズムによって指定されたとおりに、初期ポリシー識別子を設定します。 Set の要素は、String として表現されたオブジェクト識別子 (OID) です。 initialPolicies パラメータが null であるか、または設定されていない場合、どのポリシーも受入れ可能です。
	public void setInitialPolicies(Set initialPolicies)
setDate メソッドは、パスの妥当性を判定するための時間を設定します。 date パラメータが設定されていないか、または null である場合、現在の日付が使用されます。
	public void setDate(Date date)
setPolicyMappingInhibited メソッドは、ポリシーマッピング禁止フラグの値を設定します。指定されていない場合、フラグのデフォルト値は false です。
	public void setPolicyMappingInhibited(boolean val)
setExplicitPolicyRequired メソッドは、明示的なポリシー要求フラグの値を設定します。指定されていない場合、フラグのデフォルト値は false です。
	public void setExplicitPolicyRequired(boolean val)
setAnyPolicyInhibited メソッドは、ポリシー禁止フラグの値を設定します。指定されていない場合、フラグのデフォルト値は false です。
	public void setAnyPolicyInhibited(boolean val)
setTargetCertConstraints メソッドを使用すると、呼び出し側は、ターゲットまたはエンドエンティティの証明書に制約を設定できます。たとえば、呼び出し側は、ターゲットの証明書に特定の主体名を含むよう指定できます。制約は、CertSelector オブジェクトとして指定されます。 selector パラメータが null であるか、または設定されていない場合、ターゲットの証明書に制約は定義されません。
	public void setTargetCertConstraints(CertSelector selector)
setCertStores メソッドを使用すると、呼び出し側は、CertPathValidator の PKIX 実装がパスの検証用の CRL を検索するために使用する CertStore オブジェクトの List を指定できます。これにより、CRL の位置を指定する拡張可能な機構が提供されます。 setCertStores メソッドは、CertStore オブジェクトの List をパラメータとして取得します。リスト中の最初の CertStore は、後のエントリに優先します。
	public void setCertStores(List stores)
setCertPathCheckers メソッドを使用すると、呼び出し側は、実装に固有の証明書パスのチェッカを生成することによって PKIX 検証アルゴリズムを拡張できます。たとえば、この機構は、非公開証明書の拡張情報を処理するために使用されます。 setCertPathCheckers メソッドは、PKIXCertPathChecker オブジェクト (後述) のリストをパラメータとして取得します。
	public void setCertPathCheckers(List checkers)
setRevocationEnabled メソッドを使用すると、呼び出し側は取り消しのチェックを無効にすることができます。取り消しのチェックは、PKIX 検証アルゴリズムに必要なチェックなので、デフォルトでは有効になっています。ただし、PKIX では、取り消しのチェック方法は定義しません。たとえば、実装は CRL または OCSP を使用することがあります。このメソッドを使用すると、呼び出し側は、実装でデフォルトに設定された取り消しチェック機構が適当でない場合に、それを無効にできます。その後で、setCertPathCheckers メソッドを呼び出し、代わりとなる機構を実装する PKIXCertPathChecker に渡すことにより、別の取り消しチェック機構を指定できます。
	public void setRevocationEnabled(boolean val)
setPolicyQualifiersRejected メソッドを使用すると、呼び出し側は、ポリシー修飾子の処理を有効または無効に設定できます。 PKIXParameters オブジェクトが生成されると、このフラグは true に設定されます。この設定は、ポリシー修飾子を処理するための最も一般的な (かつ簡単な) 方法を反映します。より複雑なポリシーを使用するアプリケーションでは、このフラグを false に設定する必要があります。
	public void setPolicyQualifiersRejected(boolean qualifiersRejected)
パラメータ値の取得

各パラメータの現在の値は、該当する get メソッドを使って取得できます。これらのメソッドの詳細については、PKIXParameters の API ドキュメントを参照してください。
PKIXCertPathValidatorResult クラス

このクラス (CertPathValidatorResult インタフェースを実装) は、PKIX 証明書パス検証アルゴリズムの結果を表します。有効なポリシーツリーおよび検証アルゴリズムによって生成された主体の公開鍵を保持し、これらを返すためのメソッド (getPolicyTree() および getPublicKey()) を持ちます。 PKIXCertPathValidatorResult のインスタンスは、PKIX アルゴリズムを実装する CertPathValidator オブジェクトの validate メソッドによって返されます。

このクラスの詳細については、PKIXCertPathValidatorResult の API ドキュメントを参照してください。

PolicyNode インタフェースおよび PolicyQualifierInfo クラス

PKIX 検証アルゴリズムは、証明書ポリシー処理に関連のあるいくつかの出力を定義します。ほとんどのアプリケーションは、これらの出力を使用する必要はありませんが、PKIX 検証を実装しているかまたはアルゴリズムを構築しているプロバイダはすべて、それらの出力をサポートする必要があります。
PolicyNode インタフェースは、PKIX 証明書パス検証が正常に実行されると作成される有効なポリシーツリーを表します。アプリケーションは、PKIXCertPathValidatorResult の getPolicyTree メソッドを使って、有効なポリシーツリーのルートを取得できます。ポリシーツリーの詳細については、「PKIX Certificate and CRL profile」を参照してください。
PolicyNode の getPolicyQualifiers メソッドは、PolicyQualifierInfo オブジェクトの Set を返します。その各オブジェクトは、このポリシーが適用される適切な証明書の Certificate Policies 拡張情報に含まれるポリシー修飾子を表します。
ほとんどのアプリケーションでは、有効なポリシーツリーおよびポリシー修飾子を調べる必要はありません。 PKIXParameters でポリシー関連のパラメータを設定することにより、アプリケーションのポリシー処理目標を実現できます。ただし、有効なポリシーツリーは、より複雑なアプリケーション、特にポリシー修飾子を処理するアプリケーションに利用できます。
これらのクラスの詳細については、 PolicyNode および PolicyQualifierInfo の API ドキュメントを参照してください。
PKIX アルゴリズムを使った証明書パスの検証例

ここでは、PKIX 検証アルゴリズムを使った証明書パスの検証の例を取り上げます。例では、ほとんどの例外処理を無視し、信頼できるアンカーの証明書パスおよび公開鍵がすでに作成されているものと仮定します。
まず、次の行のようにして、CertPathValidator を生成します。
    CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
次の手順で、TrustAnchor オブジェクトを生成します。このオブジェクトは、証明書パスの検証にアンカーとして使用されます。この例では、最も信頼できる CA は公開鍵および名前 (名前制約は適用されず、null として指定される) として指定されます。
    TrustAnchor anchor = new TrustAnchor("O=xyz,C=us", pubkey, null);
次の手順で、PKIXParameters オブジェクトを生成します。これを使って、PKIX アルゴリズムで使用されるパラメータを移植します。この例では、コンストラクタに、前の手順で作成した要素 TrustAnchor を 1 つだけ含む Set を渡します。
    PKIXParameters params = new PKIXParameters(Collections.singleton(anchor));
次に、検証アルゴリズムにより使用される制約またはその他のパラメータを持つ、パラメータオブジェクトを生成します。この例では、explicitPolicyRequired フラグを有効にし、初期ポリシー OID のセット (セットの内容は示されない) を指定します。
    // set other PKIX parameters here
    params.setExplicitPolicyRequired(true);
    params.setInitialPolicies(policyIds);
最後の手順は、生成済みの入力パラメータセットを使った証明書パスの検証です。
    try {
        PKIXCertPathValidatorResult result =
            (PKIXCertPathValidatorResult) cpv.validate(certPath, params);
        PolicyNode policyTree = result.getPolicyTree();
        PublicKey subjectPublicKey = result.getPublicKey();
    } catch (CertPathValidatorException cpve) {
        System.out.println("Validation failure, cert["
            + cpve.getIndex() + "] :" + cpve.getMessage());
    }
検証アルゴリズムが成功したら、その検証アルゴリズムで生成されたポリシーツリーおよび主体の公開鍵を、PKIXCertPathValidatorResult の getPolicyTree および getPublicKey メソッドを使って取得します。
そうでない場合は、CertPathValidatorException がスローされるため、呼び出し側は例外をキャッチして、エラーメッセージや障害を引き起こした証明書のインデックスなど、障害のいくつかの詳細について表示できます。
PKIXBuilderParameters クラス

PKIXParameters クラスを拡張するこのクラスは、PKIX 証明書パスの検証アルゴリズムに従って検証される証明書パスを構築する CertPathBuilder に使用されるパラメータのセットを指定します。

PKIXBuilderParameters オブジェクトは、PKIX アルゴリズムを実装した CertPathBuilder インスタンスの build メソッドに引数として渡されます。すべての PKIX CertPathBuilder は、PKIX 証明書パスの検証アルゴリズムに従って検証されている証明書パスを返す必要があります。
PKIX CertPathBuilder が構築されたパスの検証に使用する機構が、実装の詳細であることに注目してください。たとえば、実装はまず、最低限の検証を行ったパスを構築し、次に PKIX CertPathValidator のインスタンスを使ってパスを完全に検証します。より効率的な実装は、パスの構築中に多くのパスを検証し、検証の障害または行き詰まりが発生した場合には、前の段階に戻ります。
PKIXBuilderParameters オブジェクトの生成

PKIXBuilderParameters オブジェクトの生成は、PKIXParameters オブジェクトの生成と同様です。ただし、PKIXBuilderParameters オブジェクトを生成するときに、呼び出し側は、ターゲットまたはエンドエンティティの証明書に制約を指定する必要があります。これらの制約は、ターゲットの証明書を探すのに十分な情報を CertPathBuilder に提供する必要があります。制約は、CertSelector オブジェクトとして指定されます。次の制約のうちの 1 つを使って、PKIXBuilderParameters オブジェクトを生成します。
	public PKIXBuilderParameters(Set trustAnchors,
		CertSelector targetConstraints)
		throws InvalidAlgorithmParameterException
	public PKIXBuilderParameters(KeyStore keystore,
		CertSelector targetConstraints)
		throws KeyStoreException, InvalidAlgorithmParameterException
パラメータ値の取得/設定

PKIXBuilderParameters クラスは、PKIXParameters クラスで設定できるすべてのパラメータを継承します。さらに、setMaxPathLength メソッドを呼び出して、証明書パス内の最大数の証明書に制限を設定することもできます。
	public void setMaxPathLength(int maxPathLength)
maxPathLength パラメータは、証明書パスに存在できる非自動発行の中間証明書の最大数を指定します。 PKIX アルゴリズムを実装している CertPathBuilder インスタンスでは、指定された長さよりも長いパスを構築することはできません。値が 0 の場合、パスは単一の証明書だけを含むことができます。値が � の場合、パスの長さは制約を受けません (つまり上限はない)。最大パス長を指定しなかった場合、デフォルトの 5 になります。このメソッドは、呼び出し側の要求を満たすかどうかにかかわりなく、CertPathBuilder が長いパスを構築するのにリソースおよび時間を費やさないようにするために便利です。

パス内の CA 証明書に Basic Constraints 拡張機能が含まれている場合、結果がより短い証明書パスの時は、常に拡張機能の pathLenConstraint コンポーネントの値で maxPathLength パラメータの値をオーバーライドします。また、対応する getMaxPathLength メソッドにより、このパラメータを取得することもできます。
	public int getMaxPathLength()
また、PKIXParameters クラスから継承された setCertStores メソッドは、通常、CertPathBuilder の PKIX 実装によって、パスを検証するための CRL の検索だけでなく、パスを構築するための証明書の検索にも使用されます。これにより、証明書および CRL の位置を指定する拡張可能な機構が提供されます。
PKIXCertPathBuilderResult クラス

このクラス (PKIXCertPathValidatorResult クラスを拡張し CertPathBuilderResult インタフェースを実装) は、PKIX 証明書パス構築アルゴリズムの結果が成功であることを示します。PKIX アルゴリズムを実装する CertPathBuilder オブジェクトの build メソッドにより、PKIXCertPathBuilderResult のインスタンスが返されます。

PKIXCertPathBuilderResult インスタンスの getCertPath メソッドは、常に PKIX 証明書パスの検証アルゴリズムを使って検証された CertPath オブジェクトを返します。返された CertPath オブジェクトには、パスの固定に使用されていた最も信頼できる CA 証明書が含まれません。代わりに、getTrustAnchor メソッドを使って、最も信頼できる CA の Certificate を取得します。

このクラスの詳細については、PKIXCertPathBuilderResult の API ドキュメントを参照してください。

PKIX アルゴリズムを使った証明書パスの構築例

これは、PKIX アルゴリズムに従って検証される証明書パスの構築例です。例外処理、および CertStore の生成用に信頼できるアンカーおよび証明書の生成する場合など、除外されている詳細もあります。
まず、次の例にあるように、CertPathBuilder を生成します。
    CertPathBuilder cpb = CertPathBuilder.getInstance("PKIX");
この呼び出しは、PKIX アルゴリズムに従って検証されるパスを返す CertPathBuilder オブジェクトを生成します。

次の手順では、PKIXBuilderParameters オブジェクトを生成します。これは、CertPathBuilder により使用される PKIX パラメータの生成に使用されます。
    // Create parameters object, passing it a Set of
    // trust anchors for anchoring the path
    // and a target subject DN.
    X509CertSelector targetConstraints = new X509CertSelector();
    targetConstraints.setSubject("CN=alice,O=xyz,C=us");
    PKIXBuilderParameters params =
        new PKIXBuilderParameters(trustAnchors, targetConstraints);
次の手順では、CertPathBuilder が証明書および CRL の検索に使用する CertStore を指定します。この例では、証明書および CRL を使用して Collection CertStore を生成します。
    CollectionCertStoreParameters ccsp =
	new CollectionCertStoreParameters(certsAndCrls);
    CertStore store = CertStore.getInstance("Collection", ccsp);
    params.addCertStore(store);
次の手順では、生成済みの入力パラメータセットを使って証明書パスを構築します。
    try {
        PKIXCertPathBuilderResult result =
	    (PKIXCertPathBuilderResult) cpb.build(params);
        CertPath cp = result.getCertPath();
    } catch (CertPathBuilderException cpbe) {
	System.out.println("build failed: " + cpbe.getMessage());
    }
CertPathBuilder は、指定されたパラメータを満たすパスを構築できない場合、CertPathBuilderException をスローします。そうでない場合、検証された証明書パスは、getCertPath メソッドを使ってPKIXCertPathBuilderResult から取得できます。
PKIXCertPathChecker クラス

ここでは、ユーザが PIKX CertPathValidator または CertPathBuilder 実装を拡張できるようにする強力なクラスを説明します。これは、ほとんどのユーザは理解する必要のない高度な機能です。ただし、PKIX サービスプロバイダを実装している方は、この項をお読みください。

PKIXCertPathChecker クラスは、X.509 証明書で 1 つ以上のチェックを実行する abstract クラスです。開発者は、実行時に PKIX CertPathValidator または CertPathBuilder 実装を動的に拡張する必要がある場合、PKIXCertPathChecker クラスの固定実装を作成する必要があります。 PKIXCertPathChecker 実装が役立つ例のいくつかを次に示します。

PKIX CertPathValidator または CertPathBuilder 実装によって提供される取り消し機構が適さない場合。たとえば、開発者は、証明書が取り消されていないことを確認するために OCSP ( RFC 2560) を使用する PKIXCertPathChecker を実装することができます。

ユーザが重要な非公開の拡張情報を含む証明書を識別したい場合。拡張情報は非公開なので、PKIX CertPathValidator または CertPathBuilder 実装によって認識されず、CertPathValidatorException がスローされます。この場合、開発者は重要な非公開の拡張情報を認識して処理する PKIXCertPathChecker を実装できます。

開発者が、デバッグ時に処理される各証明書についての情報を記録したい、または目的を表示したい場合。

ユーザが特定のポリシー修飾子を持つ証明書を拒否したい場合。

PKIXParameters クラスの setCertPathCheckers メソッドを使用すると、ユーザは PKIXCertPathChecker オブジェクトの List を PKIX CertPathValidator または CertPathBuilder 実装に渡すことができます。各 PKIXCertPathChecker オブジェクトは、PKIX CertPathValidator または CertPathBuilder 実装によって処理される証明書ごとに、順次呼び出されます。
PKIXCertPathChecker オブジェクトの生成および使用

PKIXCertPathChecker クラスには、public コンストラクタはありません。 PKIXCertPathChecker のインスタンスの生成は実装に固有の問題なので、あえてこのようになっています。たとえば、証明書の取り消し状態のチェックに OCSP を使用する PKIXCertPathChecker 実装のコンストラクタは、OCSP サーバのホスト名およびポートを要求できます。
	PKIXCertPathChecker checker = new OCSPChecker("ocsp.sun.com", 1321);
チェッカのインスタンスが生成されると、PKIXParameters クラスの addCertPathChecker メソッドを使って、パラメータとして追加できます。
	params.addCertPathChecker(checker);
また、チェッカの List は、PKIXParameters クラスの setCertPathCheckers メソッドを使って追加できます。

PKIXCertPathChecker オブジェクトの実装

PKIXCertPathChecker クラスは、抽象クラスです。このクラスには 4 つのメソッド (check、getSupportedExtensions、init、および isForwardCheckingSupported) があり、すべての固定サブクラスはこれらを実装する必要があります。

PKIXCertPathChecker の実装は、簡単な場合と複雑な場合があります。 PKIXCertPathChecker 実装には、状態のない場合と状態のある場合があります。状態のない実装では、check メソッドの連続する呼び出しの間で、状態が維持されません。たとえば、特定のポリシー修飾子を含む各証明書を確認する PKIXCertPathChecker は、状態がありません。それに対して、状態のある実装では、check メソッドの連続する呼び出しの間で、状態を維持します。通常、状態のある実装の check メソッドは、証明書パス内の以前の証明書の内容に依存します。たとえば、拡張情報を処理する PKIXCertPathChecker は、状態があります。

また、PKIXCertPathChecker に提供される (渡される) サービスプロバイダ実装によって処理される証明書の順序は、実装に状態がある場合は特に重要です。サービスプロバイダが使用するアルゴリズムによっては、証明書は、「逆」方向または「順」方向に渡されます。逆方向とは、証明書が最も信頼できる CA (存在する場合) からターゲットの主体へと順序づけられていることを意味します。それに対して順方向とは、証明書がターゲットの主体から最も信頼できる CA へと順序づけられていることを意味します。 PKIXCertPathChecker 実装には、連続した証明書の処理方法を理解できるようにするため、順序を知らせる必要があります。
PKIXCertPathChecker オブジェクトの初期化

init メソッドは、チェッカの内部状態を初期化します。
	public abstract void init(boolean forward)
すべての状態がある実装は、チェッカの内部状態をクリアまたは初期化する必要があります。こうすれば、サービスプロバイダ実装は、初期化されていない状態のチェッカを呼び出すことができません。また、状態のあるチェッカは、インスタンスを再度生成しなくても、以降の操作でそれを再利用できます。 forward パラメータは、PKIXCertPathChecker に渡される証明書の順序を示します。 forward が true である場合、証明書はターゲットから信頼できるアンカーに渡され、false の場合、信頼できるアンカーからターゲットに渡されます。

順方向のチェック

isForwardCheckingSupported メソッドは、PKIXCertPathChecker が順方向のチェックをサポートするかどうかを示す boolean を返します。
	public abstract boolean isForwardCheckingSupported()
すべての PKIXCertPathChecker 実装は、逆方向のチェックをサポートしている必要があります。 PKIXCertPathChecker 実装は、順方向のチェックをサポートすることができます。

順方向のチェックをサポートすると、パスが構築時にチェックされるので、順方向に構築する CertPathBuilder の効率が向上します。ただし、状態のある PKIXCertPathChecker では、順方向チェックのサポートが難しいか、または不可能な場合があります。
サポートされる拡張情報

getSupportedExtensions メソッドは、PKIXCertPathChecker 実装がサポートする X.509 拡張情報の不変の OID String の Set を返します。
	public abstract Set getSupportedExtensions()
拡張情報が処理されない場合、メソッドは null を返す必要があります。すべての実装は、check メソッドが処理する OID String の Set を返す必要があります。

CertPathBuilder は、この情報を使って、順方向のチェックをサポートしない PKIXCertPathChecker で順方向の構築を実行しているときでも、認識されない重要な拡張情報を含む証明書を識別することができます。
チェックの実行

次のメソッドは、証明書に対するチェックを実行します。
	public abstract void
	        check(Certificate cert, Collection unresolvedCritExts)
        	throws CertPathValidatorException
unresolvedCritExts パラメータには、OID のコレクションが String として含まれています。これらの OID は、まだ証明書パスの検証アルゴリズムで解釈されていない証明書内の重要な拡張情報のセットを表します。 check メソッドの固定実装は、unresolvedCrit.Exts パラメータから処理するすべての重要な拡張情報を削除する必要があります。

証明書が確認に合格しない場合、CertPathValidatorException がスローされる必要があります。

PKIXCertPathChecker の複製

PKIXCertPathChecker クラスは、Cloneable インタフェースを実装します。すべての状態のある PKIXCertPathChecker 実装は、必要に応じて、clone メソッドをオーバーライドする必要があります。 clone メソッドのデフォルトの実装は、Object.clone メソッドを呼び出します。このメソッドは、元のオブジェクトのすべてのフィールドを新しいオブジェクトにコピーすることにより、簡単な複製を実行します。状態のない実装は、clone メソッドをオーバーライドしません。ただし、すべての状態のある実装は、デフォルトの clone メソッドが正しいことを確認し、必要に応じてそれをオーバーライドする必要があります。たとえば、配列内の状態を格納する PKIXCertPathChecker は、配列を参照するだけではなく、配列のコピーを作成するため、clone メソッドをオーバーライドする必要があります。

PKIXCertPathChecker オブジェクトが Cloneable である理由は、潜在的な証明書パスが行き詰まったり、障害ポイントに到達した場合、CertPathBuilder 実装が効率的に戻り、別のパスを試すことができるようにするためです。この場合、実装は、複製されたオブジェクトを復元することにより、以前のパスの検証状態を復元することができます。
例

これは、状態のない PKIXCertPathChecker 実装の例です。非公開の拡張情報が証明書に存在するかどうかをチェックし、いくつかの規則に従って処理します。
	import java.security.cert.Certificate;
	import java.security.cert.X509Certificate;
	import java.util.Collection;
	import java.util.Collections;
	import java.util.Set;
	import java.security.cert.PKIXCertPathChecker;
	import java.security.cert.CertPathValidatorException;

	public class MyChecker extends PKIXCertPathChecker {
	    private static Set supportedExtensions =
	        Collections.singleton("2.16.840.1.113730.1.1");

	    /*
 	     * Initialize checker
	     */
	    public void init(boolean forward)
		throws CertPathValidatorException {
		// nothing to initialize
	    }

	    public Set getSupportedExtensions() {
		return supportedExtensions;
	    }

	    public boolean isForwardCheckingSupported() {
		return true;
	    }

	    /*
	     * Check certificate for presence of Netscape's
	     * private extension
	     * with OID "2.16.840.1.113730.1.1"
	     */
	    public void check(Certificate cert,
			      Collection unresolvedCritExts)
		throws CertPathValidatorException
	    {
		X509Certificate xcert = (X509Certificate) cert;
	        byte[] ext =
		    xcert.getExtensionValue("2.16.840.1.113730.1.1");
		if (ext == null)
		    return;

		//
	        // process private extension according to some
		// rules - if check fails, throw a
		// CertPathValidatorException ...
		// {insert code here}

		// remove extension from collection of unresolved
		// extensions (if it exists)
		if (unresolvedCritExts != null)
		    unresolvedCritExts.remove("2.16.840.1.113730.1.1");
	    }
	}
PKIX サービスプロバイダ実装による PKIXCertPathChecker の使用方法

各 PKIXCertPathChecker オブジェクトは、構築または検証アルゴリズムを開始する前に、サービスプロバイダ実装によって初期化される必要があります。次に例を示します。
	List checkers = params.getCertPathCheckers();
	ListIterator li = checkers.listIterator();
	while (li.hasNext()) {
	    PKIXCertPathChecker checker = (PKIXCertPathChecker) li.next();
	    checker.init(false);
	}
検証する証明書ごとに、サービスプロバイダ実装は各 PKIXCertPathChecker オブジェクトの check メソッドを順に呼び出し、証明書および残りの解釈されていない重要な拡張情報に渡します。
	ListIterator li = checkers.listIterator();
	while (li.hasNext()) {
	    PKIXCertPathChecker checker = (PKIXCertPathChecker) li.next();
	    checker.check(cert, unresolvedCritExts);
	}
check のどれかが CertPathValidatorException をスローする場合、CertPathValidator 実装は、検証手順を終了する必要があります。ただし、CertPathBuilder 実装は、単に障害を記録し、引き続きその他の潜在的なパスを探す場合があります。サービスプロバイダ実装は、すべての check が成功した場合、解釈されているすべての重要な拡張情報をチェックします。そうでない場合、失敗した検証について検討する必要があります。例を示します。
	if (unresolvedCritExts != null &&
	    !unresolvedCritExts.isEmpty())
	{
            // note that a CertPathBuilder may have an enclosing
            // try block to catch the exception below and continue on error
	    throw new CertPathValidatorException
		("Unrecognized Critical Extension");
	}
前のセクションで説明したように、実装は、潜在的な証明書パスが行き詰まったり、障害ポイントにおよんだ場合は、戻る必要があります。ここで戻るというのは、パス内の以前の証明書に戻り、その他の潜在的なパスを探すことを意味します。 CertPathBuilder 実装がパスの構築中にパスを検証する場合、各 PKIXCertPathChecker の以前の状態を復元する必要があります。これを行うには、各証明書が処理される前に、PKIXCertPathChecker オブジェクトを複製します。例を次に示します。
	/* clone checkers */
	List newList = new ArrayList(checkers);
	ListIterator li = newList.listIterator();
	while (li.hasNext()) {
	    PKIXCertPathChecker checker = (PKIXCertPathChecker) li.next();
	    li.set(checker.clone());
	}
サービスプロバイダの実装

このセクションは、証明書パスサービス実装を提供する独自のプロバイダパッケージを作成する上級プログラマを対象としています。このセクションの記述は、「Java 暗号化アーキテクチャ用プロバイダの実装方法」をすでに読んでいることを前提としています。

Java Certification Path API では、次のエンジンクラスが定義されています。

CertPathValidator - 証明書パスの検証に使用される

CertPathBuilder - 証明書パスの構築に使用される

CertStore - リポジトリから証明書および CRL を取得するために使用される

さらに、既存の CertificateFactory エンジンクラスは、J2SDK, v1.4 で拡張されており、証明書パスの生成をサポートします。

エンジンクラスが提供するアプリケーションインタフェースは、「Service Provider Interface (SPI)」として実装されます。 SPI クラスの名前は、対応するエンジンクラス名のあとに「Spi」を追加した名前になります。たとえば、CertPathValidator エンジンクラスに対応する SPI クラスは、CertPathValidatorSpi クラスです。各 SPI クラスは、抽象クラスです。個々のアルゴリズムまたは型について、特定の型のサービスの実装を提供するには、プロバイダは対応する SPI クラスをサブクラス化して、すべての抽象メソッドの実装を提供する必要があります。たとえば、CertStore クラスは、証明書および CRL をリポジトリから取得する機能を利用できるようにします。 CertStoreSpi サブクラスで提供される実際の実装は、LDAP など、特定の型の証明書リポジトリのための実装です。

プロバイダの実装および統合までのステップ

開発者は、「Java 暗号化アーキテクチャ用プロバイダの実装方法」ドキュメントに示されたステップに従う必要があります。ここでは、特定のステップを補足するいくつかの付加的な規則について説明します。

ステップ 3: プロバイダのサブクラスである「マスタークラス」の記述

次のプロパティを、証明書パスサービス用に定義する必要があります。証明書パスサービスでは、アルゴリズム名は algName に置き換えられ、certstore 型は storeType に置き換えられます。

CertPathValidator.algName

CertPathBuilder.algName

CertStore.storeType

algName および storeType に定義される標準名については、付録 A を参照してください。各プロパティの値は、指定されたアルゴリズムを実装するクラスの完全修飾名、、または certstore 型である必要があります。つまり、クラス名の後にピリオドとパッケージ名が記述されていなければなりません。たとえば、プロバイダは、次のようにして CertPathValidator.PKIX プロパティを設定し、値「sun.security.provider.certpath.PKIXCertPathValidator」を保持します。
put("CertPathValidator.PKIX", "sun.security.provider.certpath.PKIXCertPathValidator")

さらに、サービス属性を証明書パスサービス用に定義することができます。これらの属性は、サービスプロバイダを選択するためのフィルタとして使用できます。標準のサービス属性の定義については、付録 A を参照してください。たとえば、プロバイダが ValidationAlgorithm サービス属性を PKIX 検証アルゴリズムを定義する仕様または RFC の名前に設定している場合があります。
put("CertPathValidator.PKIX ValidationAlgorithm", "RFC2459");

ステップ 8: プロバイダおよびそのサポート対象サービスのドキュメント化

証明書パスサービスプロバイダは、SPI ごとに次の情報をドキュメント化する必要があります。

証明書ファクトリ
プロバイダは、ファクトリが作成できる証明書パスの種類 (および必要に応じてパス内の証明書のバージョン番号) をドキュメント化する必要があります。プロバイダは、内容だけでなく、証明書パスの証明書の順序を記述する必要があります。

プロバイダは、サポートされている符号化形式のリストをドキュメント化する必要があります。クライアントは getCertPathEncodings メソッドを呼び出して符号化形式を要求できるので、技術的にはこの作業は必要ありません。ただし、ドキュメントには各符号化形式について詳細に記述し、該当する場合は、標準について言及する必要があります。

証明書パスの検証
プロバイダは、検証する証明書パスの種類など、CertPathValidator 実装についての関連情報をドキュメント化する必要があります。特に、PKIX CertPathValidator 実装は、次の情報をドキュメント化する必要があります。

準拠した RFC または仕様
証明書が取り消されていないことをチェックするために使用する機構
認識するオプションの証明書または CRL 拡張機能、およびそれらを処理する方法

証明書パスの構築

プロバイダは、作成する証明書パスの種類、およびそれらのパスが検証されているかどうかなど、CertPathBuilder 実装の関連情報をドキュメント化する必要があります。特に、 PKIX CertPathBuilder 実装は、次の情報をドキュメント化する必要があります。

準拠した RFC または仕様
証明書が取り消されていないことをチェックするために使用する機構
認識するオプションの証明書または CRL 拡張機能、およびそれらを処理する方法
証明書パスの検索に使用するアルゴリズムの詳細。例: 深さ優先、幅優先、順方向 (つまり、ターゲットから信頼できるアンカーへ)、逆方向 (つまり、信頼できるアンカーからターゲットへ)
潜在的な証明書の選択およびソートに使用されるアルゴリズム。たとえば、パス内に次の証明書の候補になりうる 2 つの証明書がある場合、一方を先に選択するためにどの条件を使用するか。証明書の拒否にどの条件を使用するか
該当する場合、別のパスに戻る、または別のパスを構築する際に使用するアルゴリズム (つまり、潜在的なパスが制約に適合しない場合)
テスト済みの CertStore 実装の型。実装は、どの CertStore 型でも動作するように設計されている必要があるが、それでもなおこの情報が役立つことがある

すべての CertPathBuilder 実装は、潜在的なパスの構築に関する問題を分析および修正するため、付加的なデバッグサポートを提供する必要があります。このデバッグ情報へのアクセス方法の詳細については、ドキュメント化されている必要があります。

証明書/CRL ストア

プロバイダは、CertStore によって取得される証明書および CRL の種類 (および必要に応じてバージョン番号) をドキュメント化する必要があります。

また、プロバイダは、CertStore 実装に関するすべての情報 (使用されるプロトコルまたはサポートされる形式など) をドキュメント化する必要があります。たとえば、LDAP CertStore 実装では、どのバージョンの LDAP がサポートされているのか、およびどの標準属性が証明書および CRL の検索に使用されるのかを記述する必要があります。また、実装が結果をキャッシュするかどうか、およびその期間 (つまりリフレッシュの条件) をドキュメント化する必要があります。

実装が、特定の順序で証明書および CRL を返す場合、ソートアルゴリズムを記述する必要があります。また、実装は、すべての追加またはデフォルトの初期化パラメータを記述する必要があります。

最後に、実装は証明書および CRL の検索に、CertSelector または CRLSelector オブジェクトの情報を使用するかどうか、およびその方法をドキュメント化する必要があります。

サービスの相互依存性

ここでは、証明書パスサービス実装におけるアルゴリズムの相互依存の一般的な種類を示します。

証明書パスの検証および署名アルゴリズム

CertPathValidator 実装は、各証明書のデジタル署名を検証するため、署名アルゴリズムの使用を要求する場合があります。 PKIXParameters クラスの setSigProvider メソッドにより、ユーザは特定の Signature プロバイダを指定できます。

証明書パスの構築および証明書ファクトリ

CertPathBuilder 実装は、証明書のリストから証明書パスを生成するため、CertificateFactory を使用する場合があります。

CertStores および証明書ファクトリ

CertStore 実装は、証明書および CRL を符号化から生成するため、CertificateFactory を使用することがあります。たとえば、LDAP CertStore 実装は、X.509 CertificateFactory を使用して、ASN.1 符号化形式から X.509 証明書および CRL を生成します。

証明書パスパラメータ仕様のインタフェース

Certification Path API には、パラメータの透過的な仕様を表す CertPathParameters および CertStoreParameters という 2 つのインタフェースが含まれています。

CertPathParameters インタフェースの 2 つの実装として、PKIXParameters および PKIXBuilderParameters クラスが含まれています。 PKIX 証明書パスの検証およびアルゴリズムパラメータを使って作業する場合、これらのクラスを利用できます。アルゴリズムごとにパラメータが必要な場合は、そのアルゴリズムに独自の CertPathParameters 実装を提供する必要があります。

CertStoreParameters インタフェースには、LDAPCertStoreParameters および CollectionCertStoreParameters クラスという 2 つの実装が含まれています。これらのクラスは、LDAP および Collection CertStore 実装で別々に使用されます。別々のリポジトリ型にパラメータが必要な場合は、その型の独自の CertStoreParameters 実装を提供する必要があります。
CertPathParameters および CertStoreParameters インタフェースは、それぞれ実装がオーバーライドする必要のある clone メソッドを定義します。標準的な実装は、オブジェクトの「ディープ」コピーを実行し、それ以降コピーに対して行われる変更が元のオブジェクトに影響しないように (逆の場合も同様) します。ただし、これは、CertStoreParameters の実装の絶対的な要件ではありません。 clone の浅いコピー実装は、CertStoreParameters に含まれるパラメータの参照を維持する必要があるアプリケーションに適しています。たとえば、CertStore.getInstance は指定された CertStoreParamter の複製を作成するので、アプリケーションはガベージコレクション機構を待つのではなく、clone の浅いコピーを使って特定の CertStore 初期化パラメータのリソースへの参照を維持し、後でリリースすることができます。 CertStore がその他のスレッドによって使用されていることがあるので、この操作は細心の注意を払って行う必要があります。

証明書パスの結果の仕様インタフェース

Certification Path API には、結果の透過的な仕様を表す CertPathValidatorResult および CertPathBuilderResult という 2 つのインタフェースが含まれます。

各インタフェースの実装には、それぞれ PKIXCertPathValidatorResult および PKIXCertPathBuilderResult クラスが含まれます。 PKIX 証明書パスサービスプロバイダを実装する場合、これらのクラスを使用することができます。別のアルゴリズムで証明書パスの結果が必要な場合は、そのアルゴリズムに独自の CertPathValidatorResult または CertPathBuilderResult 実装を提供する必要があります。

CertPathValidator または CertPathBuilder のPKIX 実装では、デバッグトレースなど、PKIXCertPathValidatorResult または PKIXCertPathBuilderResult の追加情報を格納することが有用な場合があります。この場合、実装は、関連情報を取得するメソッドを持つ、適切な結果クラスのサブクラスを実装する必要があります。これらのクラスは、プロバイダクラスとともに (たとえば、プロバイダ JAR ファイルの一部として) 提供される必要があります。

証明書パスの例外クラス
Certification Path API には、エラーを処理する例外クラスのセットが含まれています。 CertPathValidatorException、CertPathBuilderException、および CertStoreException は、GeneralSecurityException のサブクラスです。

サービスプロバイダ実装では、これらのクラスの拡張が必要になる場合があります。たとえば、CertPathBuilder 実装は、CertPathBuilderException がスローされるときに、デバッグトレースなどの追加情報を提供します。実装は、この情報を保持する CertPathBuilderException のサブクラスをスローします。同様に、CertStore 実装は、CertStoreException のサブクラスをスローすることにより障害が発生した場合、追加情報を提供できます。また、CertPathValidator 実装の特定の障害モードについて記述するため、CertPathValidatorException のサブクラスを実装することもできます。

どちらの場合も、新しい例外クラスはプロバイダクラスとともに (たとえば、プロバイダ JAR ファイルの一部として) 提供される必要があります。各プロバイダは、例外サブクラスをドキュメント化する必要があります。
TrustAnchor クラス

前述のように、PKIX CertPathValidator または CertPathBuilder は、TrustAnchor クラスの nameConstraints パラメータをサポートする必要はありません。実装は、このパラメータがサポートされていない場合、InvalidAlgorithmParameterException をスローする必要があります。

付録 A: 標準名

Java Certification Path API では、証明書パスの検証アルゴリズム、符号化および証明書ストレージタイプについて、標準名のセットを必要とし、それらを使用します。この API では、「Java 暗号化アーキテクチャ API 仕様およびリファレンス」の付録 A で定義されている標準名のリストを補足します。アルゴリズム名は、比較の際に大文字と小文字が区別されないことに注意してください。

サービスプロバイダは、以下に述べられていない独自のアルゴリズムまたは非標準のアルゴリズムに新しい名前を定義することもできます。ただし、名前の衝突を防止するため、プロバイダの組織のインターネットドメイン名を逆にしたもの (com.sun.MyCertPathValidator など) を名前の前に付けることをお勧めします。

CertPathValidator アルゴリズム

このセクションのアルゴリズム名は、CertPathValidator のインスタンスの生成時に指定できます。

PKIX: ValidationAlgorithm サービス属性で定義されている PKIX 証明書パスの検証アルゴリズム。

CertPathBuilder アルゴリズム

このセクションのアルゴリズム名は、CertPathBuilder のインスタンスの生成時に指定できます。

PKIX: ValidationAlgorithm サービス属性で定義されている PKIX 証明書パスの検証アルゴリズム。このアルゴリズムを実装している CertPathBuilder インスタンスの出力は、PKIX 検証アルゴリズムに従って検証された証明書パスです。

CertStore の型

次の型は、CertStore のインスタンスの生成時に指定できます。

LDAP: LDAPSchema サービス属性に定義されているスキーマを使って、証明書および CRL を LDAP ディレクトリからフェッチする CertStore 実装です。
Collection: 証明書および CRL を Collection から取得する CertStore 実装です。このタイプの CertStore は、署名付きメールメッセージや SSL ネゴシエーションなど、バッグまたはある種の添付ファイルで証明書または CRL を受信するアプリケーションで特に有用です。

CertPath 符号化

次の符号化は、CertPath の getEncoded メソッドまたは CertificateFactory の generateCertPath(InputStream inStream, String encoding) メソッドに渡されます。

PKCS7: 証明書の重要なフィールドだけを持つ PKCS#7 SignedData オブジェクト。特に、署名および内容は無視されます。証明書が存在しない場合、長さが 0 の CertPath であるとみなされます。 警告: PKCS#7 では、証明書パス内の証明書の順序は維持されません。したがって、CertPath が PKCS#7 で符号化されたバイトに変換されてから、元に戻された場合、証明書の順序が変更されたり、CertPath が無効になる場合があります。ユーザは、この動作を知っておく必要があります。

PkiPath: ASN 1 DER で符号化された証明書のシーケンス。次のように定義されます。
PkiPath ::= SEQUENCE OF Certificate

シーケンス内で、証明書は、最初の証明書の主体が 2 番目の証明書の発行元というような順序になります。PkiPath 内の各証明書は一意です。どの証明書も、PkiPath 内の Certificate の値に 1 回ずつ現れます。 PkiPath 形式は、X.509 に対する欠陥レポート 279 (2000) 内で定義されており、X.509 の Draft Technical Corrigenda 2、第 4 版 (2000) に組み込まれています
(ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/8-DTC2%284th%29.pdf)。

サービス属性

ValidationAlgorithm: CertPathBuilder または CertPathValidator がサポートする証明書パス検証アルゴリズムの実装を定義する仕様の名前。 RFC は、"RFC#" (例: "RFC2459") のように指定します。Internet Draft は、ドラフト名で指定します (例: "draft-ietf-pkix-new-part1-08.txt")。この属性の値を Security.getProviders メソッドの選択基準として指定した場合、String.equalsIgnoreCase により値の比較が行われます。 CertPathBuilder および CertPathValidator のすべての PKIX 実装は、この属性の値を提供する必要があります。

LDAPSchema: LDAP CertStore の実装が証明書と CRL の取得に使用する LDAP スキーマを定義する仕様の名前です。この属性の形式およびセマンティクスは、ValidationAlgorithm 属性の場合と同じです。 CertStore のすべての LDAP 実装は、この属性の値を提供する必要があります。

付録 B: 「SUN」プロバイダ

J2SDK で提供されている「SUN」プロバイダは、バージョン 1.4 用に拡張され、次の標準アルゴリズム、型、および符号化をサポートしています。

CertificateFactory: X.509 CertPath 型および PKCS7 PkiPath 符号化
CertPathValidator: PKIX アルゴリズム
CertPathBuilder: PKIX アルゴリズム
CertStore: LDAP および Collection CertStore 型

これらのサービスプロバイダインタフェースの実装については、それぞれ次で詳しく説明します。

CertificateFactory

CertificateFactory エンジンクラス用の「SUN」プロバイダは、X.509 CertPath オブジェクトの生成をサポートするために拡張されました。 PKCS7 および PkiPath 符号化がサポートされます。 PKCS#7 実装は、RFC 2315 のサブセットをサポートします (SignedData ContentInfo 型だけがサポートされる)。 CertPath の証明書は、順方向に (ターゲットから信頼できるアンカーへ) 順序付けされます。 CertPath の各証明書は java.security.cert.X509Certificate 型で、バージョン 1、2、および 3 がサポートされています。

CertPathValidator

「SUN」プロバイダは、CertPathValidator エンジンクラスの PKIX 実装を提供します。実装は、X.509 型の CertPath を検証し、 PKIX 証明書と CRL プロファイル用の Internet-Draft 第 9 版に定義されている証明書パス検証アルゴリズムを実装します。このドラフトが完成すると、RFC 2459 は使用されなくなります。この実装は、ValidationAlgorithm サービス属性の値を "draft-ietf-pkix-new-part1-08.txt" に設定します。

PKIX 証明書と CRL プロファイルには、多くのオプション機能があります。「SUN」プロバイダは、ポリシーマッピング拡張機能および原因コード CRL エントリ拡張機能のサポートを実装しています。 CRL 配布ポイント、Freshest CRL、Authority Information Access、または Subject Information Access 証明書拡張機能のサポートは実装していません。また、Freshest CRL、Delta CRL、および Issuing Destribution Point CRL 拡張機能と Certificate Issuer、Invalidity Date、および Hold Instruction Code CRL エントリ拡張機能のサポートは含まれません。

実装は、PKIX 証明書と CRL プロファイルのセクション 6.3 に準拠している CRL 取り消し確認機構をサポートします。アプリケーションは、PKIXParameters オブジェクトに CRL を含む 1 つ以上の CertStore を指定する必要があります。 CertPathValidator は、CertPath の証明書ごとに、指定された CertStore を検索して適切な CRL を探します。 OCSP (RFC 2560) は、現在、組み込みの取り消し確認機構としてはサポートされません。

この実装は、TrustAnchor クラスの nameConstraints パラメータをサポートしません。したがって、このパラメータが指定されると、validate メソッドにより InvalidAlgorithmParameterException がスローされます。

CertPathBuilder

「SUN」プロバイダは、CertPathBuilder エンジンクラスの PKIX 実装を提供します。実装は、X.509 型の CertPath を構築します。各 CertPath は、PKIX 証明書と CRL プロファイル用の Internet-Draft 第 9 版で定義されている PKIX アルゴリズムに従って検証されます。このドラフトが完成すると、RFC 2459 は使用されなくなります。この実装は、ValidationAlgorithm サービス属性の値を "draft-ietf-pkix-new-part1-08.txt" に設定します。

PKIXBuilderParameters オブジェクトの targetConstraints パラメータが X509CertSelector のインスタンスでなければなりません。そうでない場合、build メソッドにより InvalidAlgorithmParameterException がスローされます。

実装は、深さ優先アルゴリズムを使って、順方向にCertPath オブジェクトを構築します。潜在的なパスが無効であるか、または PKIXBuilderParameters maxPathLength パラメータを超えていると判定されると、前の状態に戻って代替パスを試みます。

パスの検証は、CertPathValidator 実装と同じ方法で実行されます。実装は、プロセスの早い段階で無効なパスを除外するために、パスの構築時にほとんどのパスを検証します。順方向に順序付けされている証明書で実行できない検証チェックは延期され、パスが構築されてから (アプリケーションに返される前に) そのパス上で実行されます。

2 つ以上の潜在的な証明書が検出され、指定された制約を満たすパスが見つかる可能性がある場合、実装は、次の条件を使って、証明書の優先順位を設定します (次の例では、TrustAnchor の識別名"ou=D,ou=C,o=B,c=A"が指定されていると仮定)。

証明書の発行者 DN が、指定された TrustAnchor のうち 1 つの DN と一致 (例: issuerDN = "ou=D,ou=C,o=B,c=A")
証明書の発行者 DN が TrustAnchor のうち 1 つの DN の子孫で、アンカーに近いほうから順に順序付けられている (例: issuerDN = "ou=E,ou=D,ou=C,o=B,c=A")
証明書の発行者 DN が TrustAnchor のうち 1 つの DN の祖先で、アンカーに近いほうから順に順序付けられている (例: issuerDN = "ou=C,o=B,c=A")
証明書の発行者 DN が TrustAnchor のうち 1 つの同じネームスペース内にあり、アンカーに近いほうから順に順序付けられている (例: issuerDN = "ou=G,ou=C,o=B,c=A")
証明書の発行者 DN が、証明書の主体 DN の祖先で、主体に近いほうから順に順序付けられている

これらの後には、上記のどの条件も満たさない証明書が続きます。

この実装は、このリリースの「SUN」プロバイダに含まれる LDAP および Collection CertStore 実装でテストされています。

デバッグのサポートは、java.security.debug プロパティを certpath に設定すると有効になります。例を示します。

	java -Djava.security.debug=certpath BuildCertPath

こうすると、追加のデバッグ情報が標準エラーに出力されます。

CertStore

「SUN」プロバイダは、CertStore エンジンクラスの 2 つの実装、Collection および LDAP をサポートします。

Collection CertStore
Collection CertStore 実装は、java.security.cert.Certificate または java.security.cert.CRL のインスタンスであるすべてのオブジェクトを保持できます。
証明書および CRL は、特定の順序で返されることはなく、複製を含みません。
LDAP CertStore
LDAP CertStore 実装は、RFC 2587 で定義されている LDAP スキーマを使って、証明書および CRL を LDAP ディレクトリから取得します。 LDAPSchema サービス属性は "RFC2587" に設定されます。
実装は、主体の値、発行者、および X509CertSelector で指定されている basicConstraints 選択条件によって、証明書を別の位置からフェッチします。実装は、次の操作をできるだけ多く実行します。

Subject non-null, basicConstraints <= -1
主体 DN の「userCertificate」属性で証明書を検索します。

Subject non-null, basicConstraints >= -1
主体 DN の「crossCertificatePair」属性の順方向の要素内にあり、かつ主体の「caCertificate」属性内にある証明書を検索します。

Issuer non-null, basicConstraints >= -1
発行者 DN の「crossCertificatePair」属性の逆方向要素内にあり、かつ発行者 DN の「caCertificate」属性内にある証明書を検索します。

どの場合も、証明書は検索結果のコレクションに追加する前に、X509CertSelector.match() を使ってチェックされます。
上記に指定した条件のどれも当てはまらない場合、提供された条件を使って証明書をフェッチできないことを示す例外がスローされます。 1 つ以上の条件が適用されたとしても、ディレクトリに証明書がない場合、返される Collection は空のままであることに注意してください。
実装は、X509CRLSelector クラスの setCertificateChecking、addIssuerName、または setIssuerNames メソッドで指定された発行者 DN から CRL をフェッチします。どちらかのメソッドを使って発行者 DN を指定しないと、実装により、指定された基準では CRL をフェッチできないことを示す例外がスローされます。それ以外の場合、CRL は次のように検索されます。
最初に、実装により発行者名のリストが作成されます。 setCertificateChecking メソッドに証明書が指定されている場合、その証明書の発行者が使用されます。それ以外の場合、addIssuerName または setIssuerNames メソッドで指定された発行者名が使用されます。
次に、発行者名のリストに対して繰り返し処理が行われます。実装は、発行者名ごとに authorityRevocationList 属性を検索し、一致する CRL が見つからない場合、発行者の certificateRevocationList 属性内を検索します。ただし、setCertificateChecking メソッドに指定された証明書から発行者名を取得した場合は例外です。この場合、発行者の authorityRevocationList 属性に対して、指定された証明書が CA 証明書であるかどうかのチェックが行われるだけになります。
すべての CRL は検索結果のコレクションに追加する前に、X509CRLSelector.match() を使ってチェックされます。
選択基準を満たす CRL が見つからない場合、空の Collection が返されます。

コメントの送付先: java-security@sun.com。これは購読リストではありません。