ネットワークワーキンググループ
Request for Comments: 2459
分類: スタンダードトラック

R. Housley
SPYRUS
W. Ford
VeriSign
W. Polk
NIST
D. Solo
Citicorp
1999年 1月

English

インターネットX.509 PKI - 証明書と CRL のプロファイル
(Internet X.509 Public Key Infrastructure Certificate and CRL Profile)

このメモの位置付け

この文書は、インターネット・コミュニティに対してインターネット・スタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものです。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照してください。このメモの配布に制限はありません。

著作権表記

Copyright (C) The Internet Society (1999).  All Rights Reserved.

要旨

このメモは、X.509 v3 証明書と X.509 v2 CRL をインターネットにおける使用のために規定します。アプローチとモデルの概要は「はじめに」で述べられています。X.509 v3 証明書のフォーマットは、インターネット ネーム フォーム(例、IP アドレス)のフォーマットとセマンテイックスに関する追加情報とともに詳細に記述されています。  標準証明書エクステンションが記述されており、ひとつの新しいインターネット専用拡張が定義されています。証明書拡張の要求されるセットが規定されています。X.509 v2 CRL フォーマットも記述されており、要求されるエクステンション セットも定義されています。X.509 証明書パス検証のためのアルゴリズムが記述されています。よく用いられるインターネット公開鍵暗号化アルゴリズム (すなわち RSA と DSA、と Diffie-Hellman )の使用のための公開鍵のフォーマットとデジタル X.509 証明書内の署名について書かれた追加的な情報が提供されています。ASN.1 モジュールと例示が付録に示されています。

この文書中のキーワード"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、RFC 2119 に記述されているように解釈されるべきものです。この文書についてのコメントは、ietf-pkix@imc.org メーリングリスト宛に送ってください。

目次

1 はじめに

2 要求事項と前提事項

2.1 通信とトポロジ
2.2 許容性基準
2.3 ユーザーの想定
2.4 管理者の想定

3 方針の概要

3.1 X.509 バージョン 3 証明書
3.2 証明書パスと信用
3.3 取消し
3.4 運用プロトコル
3.5 管理プロトコル

4 証明書と証明書エクステンション・プロファイル

4.1 基本的な証明書フィールド

4.1.1 証明書フィールド
4.1.1.1 tbsCertificate
4.1.1.2 signatureAlgorithm
4.1.1.3 signatureValue
4.1.2 TBSCertificate

4.2 標準証明書エクステンション

4.2.1 標準エクステンション
4.2.1.1 機関鍵識別子
4.2.1.2 サブジェクト鍵識別子
4.2.1.3 鍵用途
4.2.1.4 秘密鍵有効期限
4.2.1.5 証明書ポリシー
4.2.1.6 ポリシー・マッピング
4.2.1.7 サブジェクト代替名称
4.2.1.8 発行人代替名称
4.2.1.9 サブジェクト・ディレクトリ属性
4.2.1.10 基本的制約
4.2.1.11 名称制約
4.2.1.12 ポリシー制約
4.2.1.13 拡張鍵用途フィールド
4.2.1.14 CRL 配布ポイント
4.2.2 プライベート・インターネット・エクステンション
4.2.2.1 機関情報アクセス

5 CRL と CRL エクステンションの方針

5.1 CRL フィールド

5.1.1 CertificateList フィールド
5.1.1.1 tbsCertList
5.1.1.2 signatureAlgorithm
5.1.1.3 signatureValue
5.1.2 署名予定 (To Be signed) の証明書リスト

5.2 CRL エクステンション

5.2.1 機関鍵識別子
5.1.2.1 バージョン
5.1.2.2 署名
5.1.2.3 発行人名
5.1.2.4 今回の更新
5.1.2.5 次回の更新
5.1.2.6 取消された証明書
5.1.2.7 エクステンション
5.2.2 発行人代替名称
5.2.3 CRL 番号
5.2.4 デルタ CRL インジケータ
5.2.5 発行側の配布ポイント

5.3 CRL エントリ・エクステンション

5.3.1 理由コード
5.3.2 ホールド・インストラクション・コード
5.3.3 無効
5.3.4 証明書発行人

6 証明書パスの確認

6.1 基本パスの確認
6.2 パス確認の拡張

7 アルゴリズムのサポート

7.1 一方向ハッシュ関数
7.2 署名アルゴリズム
7.3 サブジェクト公開鍵アルゴリズム

8 参照文献

9 知的財産権

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

付録 A. ASN.1 に似た構造と OIDs

A.1 明示的にタグ表示されたモジュール、1988 シンタックス
A.2 暗示的にタグ表示されたモジュール、1988 シンタックス

付録 B. 1993 ASN.1 構造および OID

B.1 明示的にタグ表示されたモジュール、1993 シンタックス
B.2 暗示的にタグ表示されたモジュール、1993 シンタックス

付録 C. ASN.1 の注意事項

付録 D. 例

D.1 証明書
D.2 証明書
D.3 RSA を使用したエンド・エンティティ証明書
D.4 証明書失効リスト

付録 E. 著者のアドレス

付録 F. 著作権表示全文

 

1 はじめに English

本仕様書は、インターネットのための X.509 公開鍵インフラストラクチャ (PKI) に関する一連の規格の一部分を構成します。本仕様書は独立した文書なので、その実装は他のパートとは独立して進めることができます。

本仕様書はインターネット PKI 用の証明書および証明書失効リスト (CRL) のフォーマットとセマンティックスを規定しています。インターネット環境での証明書パスの処理手順も示されています。よく使用される暗号化アルゴリズムについてのエンコード規則が示されているほかに、本仕様書で定義あるいは参照されているすべてのデータ構造について、Abstract Syntax Notation One (ASN.1) モジュールが付録に示されています。

2章 は本文書の作成を促す要求事項とその適用範囲に影響を与える前提事項を説明しています。3章 はアーキテクチャ・モデルを示し、それが以前の IETF および ISO/IEC/ITU 規格とどのように関連しているかを説明しています。特に、本文書が IETF PEM 仕様書と ISO/IEC/ITU X.509 文書とどのように関連しているかを説明しています。

4章 は、X.509 バージョン 3 証明書を、5章 は X.509 バージョン 2 CRL をそれぞれ説明しています。インターネット PKI で便利な ISO/IEC/ITU および ANSI エクステンションも説明されています。本書の説明には、ISO/IEC/ITU 規格で使用されていた 1994 シンタックスではなく、1988 ASN.1 が使用されています。

6章 は経路確認手順を説明しています。この手順は ISO/IEC/ITU の定義に準拠していますが、一つまたはそれ以上の自己署名された信用のおける CA 証明書が使用されることを想定しています。同一の結果を得るよう実装を行う必要がありますが、指定された手順を使用する必要はありません。

7章 は公開鍵材料とデジタル署名の識別およびエンコードに関する手順を説明しています。実装に特定の暗号化アルゴリズムを使用する必要はありませんが、指定されたアルゴリズムを使用する適合実装では、ここで説明するように公開鍵材料とデジタル署名を識別しエンコードする必要があります。

本仕様書には、その実装者の手引きとなる 4 つの付録が付いています。付録 A は本仕様書で定義あるいは参照されているすべての ASN.1 構造を示しています。前述したように、本書の説明には、1994 シンタックスではなく、1988 ASN.1 が使われています。付録 B は、更新されたツールセットを使用する実装者の助けとなるように、同じ情報を 1994 ASN.1 表記法で説明してあります。付録 A と B の内容が矛盾する場合は付録 A が優先します。付録 C は本仕様書で使用されている、あまり馴染みのない ASN.1 表記法の機能をいくつか説明しています。付録 D は適合する証明書と CRL の例を示しています。

 

2 要求事項と前提事項 English

本仕様書の目的は、X. 509 テクノロジを利用したいと思っているコミュニティを対象としたインターネット・アプリケーションにおいて X.509 証明書の使用を促進する方針を構築することです。このようなインターネット・アプリケーションの例としては WWW、電子メール、ユーザー認証、IPsec などがあります。本文書は、X.509 証明書を使用するにあたっての障害を取り除くため、証明書管理システムの開発、アプリケーション・ツールの開発、およびポリシーによって決定される相互運用を容易にするための方針を定義しています。

コミュニティによっては、特殊なアプリケーション・ドメインあるいは環境に対応できるように、本書の方針に認定、保証、あるいは運用上の要求事項を追加するか、またはそれらの要求事項と本書の方針とを入替える必要があるかもしれません。本書は、普通のアプリケーションを想定して、特定の証明書あるいは CRL の発行人とは関係なく、アプリケーション開発者が必要な情報を入手できるように、頻繁に使用される属性の一般的な表現形式を定義しています。

証明書のユーザーは、認証機関 (CA) が作成した証明書ポリシーをよく検討してから、特定の証明書中の公開鍵に関連した認証サービスあるいは否認防止サービスを使用する必要があります。このため、本規格は法的な拘束力を持つ規則あるいは義務を規定していません。

属性証明書などの、補足的な認定および属性管理ツールが開発されているので、証明書に含めることのできる認証済み属性の数を制限するのもよい方法です。これらの補足的な管理ツールは、多くの認証済み属性を伝達するうえでより適切な方法を提供できる可能性があります。

2.1 通信とトポロジ English

証明書のユーザーは、使用する通信トポロジに関して、多様な環境の中で稼動しています(特にセキュアな電子メールのユーザー)。本仕様書の方針でサポートの対象となるのは、広い帯域幅、リアルタイムのIP接続、あるいは高い接続性を有していないユーザーです。本方針はまた、ファイアウォールなどのフィルタリングされた通信にも対応しています。

本方針は X.500 ディレクトリ・システムの使用を前提としていません。本方針は X.500 ディレクトリの使用を禁止するものではありませんが、証明書および CRL は他の手段でも分配できます。

2.2 許容性基準  English

インターネット公開鍵インフラストラクチャ (PKI) の目的は、決定論的な自動識別、認証、アクセス管理、および認定機能のニーズを満足することにあります。どのサービスをサポートするかで、証明書中に組入れられる属性、および証明書中に入れられる補助管理情報(ポリシー・データ、証明書パス制約など)が決まります。

2.3 ユーザーの想定  English

インターネット PKI のユーザーはクライアント・ソフトウェアを使用する人々およびプロセスです。これらのユーザーは証明書にサブジェクトとして名前が記載されています。これらのユーザーとは、電子メールを出す人や受取る人、WWW ブラウザーのクライアント、WWW サーバー、およびルーター内の IPsec キー・マネージャーなどです。本仕様書の方針は、これらのユーザーが使用するプラットフォームの限界、およびユーザー自身の能力と注意深さの限界を認識したものとなっています。このため、本方針は、ユーザーの最低限の設定責任(たとえば信用のおける CA キー、規則など)、証明書内におけるプラットフォーム使用上の明確な制約、ユーザーを悪意の諸行為から保護する証明書パスの制約、および確認機能を敏感に自動化するアプリケーションを明示しています。

2.4 管理者の想定  English

ユーザーの想定と同様に、インターネット PKI の方針は、通常 CA を運用する個人をサポートする構成となっています。管理者に無制限の選択肢を与えると、CA のごくわずかなミスで大きな影響が出る可能性が高まるのみならず、CA が作成する証明書を処理し確認するソフトウェアが非常に複雑になります。

 

3 方針の概要 English

PKIX 仕様書が想定するアーキテクチャ・モデルの概略を下記に示します。

       +---+
       | C |                       +--------------------+
       | e | <-------------------->| エンド・エンティティ |
       | r |       運用上のトラン   +--------------------+
       | t |       ザクションと           ^
       |   |      管理上のトラン          |  管理上の
       | / |       ザクション             |  トランザクション
       |   |                             |                PKI ユーザー
       | C |                             v
       | R |       -------------------+--+-----------+----------------
       | L |                          ^              ^
       |   |                          |              |  PKI 管理
       |   |                          v              |      エンティティ
       | R |                       +------+          |
       | e | <---------------------| RA   | <---+    |
       | p |  証明書の発行          +------+     |    |
       | o |                                    |    |
       | s |                                    |    |
       | i |                                    v    v
       | t |                                +------------+
       | o | <------------------------------|     CA     |
       | r |   証明書の発行                  +------------+
       | y |   CRL の発行                          ^
       |   |                                       |
       +---+                    管理               |
                                トランザクション    |
                                                   v
                                               +------+
                                               |  CA  |
                                               +------+
図 1 - PKI エンティティ 

本モデルの構成要素は次のとおりです。

エンド・エンティティ (end entity): PKI 証明書のユーザーおよび/または証明書のサブジェクトであるエンド・ユーザー・システム。
CA: 認証機関
RA: 登録機関、つまり CA がその管理機能の一部を委託するシステム (オプション)。
リポジトリィー: 証明書と CRL を保管し、それらをエンド・エンティティに分配する手段として機能するシステムあるいは分散システムの集合。

 

3.1 X.509 バージョン 3 証明書 English

公開鍵のユーザーは、これから暗号化あるいはデジタル署名メカニズムを使用しようとしている正しいリモート・サブジェクト (人あるいはシステム) が、対応する秘密鍵を所有していることに確信が持てなければなりません。この確信は公開鍵証明書を使用することで得られます。公開鍵証明書は、公開鍵の値をサブジェクトにバインドするデータ構造です。このバインドは、信用のおける CA に各証明書へデジタル署名してもらうことで保証されます。CA は、技術的な手段 (すなわちチャレンジ・レスポンス・プロトコルによる所有の証明)、秘密鍵の提示、あるいはサブジェクトによる保証に基づいてこれを保証することができます。証明書には有効期限があり、それは署名内容に記載されています。証明書の署名と有効期限は証明書を使用するクライアントが個別にチェックできるので、信用のおけない通信システムおよびサーバー・システムを介して証明書を配布することができ、証明書を使用するシステムのセキュアでないストレージにキャッシュできます。

ITU-T X.509 (旧 CCITT X.509) すなわち ISO/IEC/ITU 9594-8 (1988 年に X.500 ディレクトリ推奨規格の一部として発行された)が標準証明書フォーマットを定義しています [X.509]。1988 年の規格で定義された証明書フォーマットはバージョン 1 (v1) フォーマットと呼ばれています。X.500 が 1993 年に改訂されたとき、2 つのフィールドが追加され、バージョン 2 (v2) フォーマットとなりました。これら 2 つのフィールドはディレクトリ・アクセス管理のサポートに使用できます。

1993 年に発表されたインターネット・プライバシー強化メール (PEM) RFC には、X.509 v1 証明書に基づいた公開鍵インフラストラクチャの仕様書が含まれています [RFC 1422]。RFC 1422 を展開する試みを通して得られた経験から、v1 と v2 の証明書フォーマットにはいくつかの面で不備があることが判明しました。最も重要だったのは、PEM を設計・実装した経験によって必要であると判明した情報を伝達するには、より多くのフィールドが必要だったことでした。これらの新しい要求事項に対処するため、ISO/IEC/ITU と ANSI X9 は X.509 バージョン 3 (v3) 証明書フォーマットを開発しました。v3 フォーマットは、追加されたエクステンション・フィールドに関する条項を追加する形で v2 フォーマットを拡張したものとなっています。特定のエクステンション・フィールド・タイプは、規格で規定されても、また任意の組織あるいはコミュニティによって定義・登録されてもかまいません。1996 年 6 月にこの基本 v3 フォーマットの規格化が完了しました [X.509]。

ISO/IEC/ITU と ANSI X9 はまた、v3 エクステンション・フィールドで使用する標準エクステンションも開発しました [X.509][X9.55]。これらのエクステンションは、追加のサブジェクト識別情報、鍵属性情報、ポリシー情報、および証明書パス制約などのデータを伝達できます。

しかしながら、ISO/IEC/ITU および ANSI X9 標準エクステンションは適用範囲が非常に広くなっています。インターネットで使用できる、X.509 v3 システムの相互運用可能な実装を開発するためには、インターネットに合わせてカスタマイズした X.509 v3 エクステンションの使用方針を規定する必要があります。このため、インターネット WWW、電子メール、および IPsec アプリケーションの方針を規定することが本仕様書の目的の一つとなっています。要求事項の追加された環境は、この方針を基に構築することも、この方針の代わりに全く別のものを使用して構築することもできます。

3.2 証明書パスと信用 English

公開鍵の知識を必要とするセキュリティ・サービスのユーザーは一般に、必要となる公開鍵の入った証明書を入手して確認する必要があります。公開鍵のユーザーが、その証明書に署名した CA の公開鍵の保証済みコピー、CA の名称、および関連情報 (有効期限、名称の制約など)をまだ入手していない場合は、その公開鍵を入手するために別の証明書を必要とすることもあります。一般に、CAが署名した公開鍵の所有者(エンド・エンティティ)の証明書、および他の CA が署名したその CA 自身の証明書 (これは必要でない場合もあります)から成る一連の複数の証明書が必要です。このような一連の証明書は証明書パスと呼ばれます。証明書パスが必要となる理由は、公開鍵のユーザーは限られた数の保証済み CA 公開鍵でイニシャライズされるだけだからです。

公開鍵ユーザーが証明書パスを見つけることができるように CA を設定する方法はいくつかあります。PEM については、RFC 1422 が CA の厳密な階層構造を定義しています。PEM 認証機関には次の 3 つのタイプがあります。

(a) インターネット・ポリシー登録機関 (IPRA): Internet Society の保護の下で運営されているこの機関は、 PEM 証明階層のルート (レベル 1) として機能しています。IPRA は次のレベルの機関である PCA に対してのみ証明書を発行します。すべての証明書パスは IPRA からスタートします。

(b) ポリシー認証機関 (PCA): PCA は階層のレベル 2 にあたり、それぞれ IPRA によって証明されます。PCA は、ユーザーあるいは下位の認証機関を証明するに際してのポリシーを定めて公表しなければなりません。別個の PCA が、それぞれ異なるユーザーのニーズを満足することを目指しています。たとえば、ある PCA (組織内の PCA) は商業組織の一般的な電子メールのニーズをサポートしています。また別の PCA (高保証 PCA) は法的な拘束力を有するデジタル署名要求事項向けの、より厳しいポリシーを有しています。

(c) 認証機関 (CA): CA は階層のレベル 3 にあたりますが、それより下のレベルにもなり得ます。レベル 3 の CA は PCA によって証明されます。CA はたとえば特定の組織、特定の組織内のユニット (たとえば部、グループ、課など)、あるいは特定の地域を代表します。

RFC 1422 には名称順序規則があります。この規則においては、ある CA は自身の名称より下位の名称 (X. 500名称ツリー中の) を有するエンティティに対してしか証明書を発行することができません。PEM 証明書パスに関連する信用は PCA の名称によって示されます。この名称順序規則に従えば、PCA より下位の CA は、それが証明できる下位のエンティティの集合に対してのみ効力を有します (たとえば、ある組織の CA はその組織の名称ツリー中のエンティティのみを証明できます)。証明書ユーザー・システムは、名称順序規則が守られているかどうかを機械的にチェックすることができます。

RFC 1422 は X.509 v1 証明書フォーマットを使用します。X.509 v1 の制約によって、ポリシー情報を明確に関連付けるかあるいは証明書のユーティリティを制限するために、いくつかの構造上の制約が課されました。これらの制約の例としては次のものがあります。

(a) 純粋な上から下への階層。すべての証明書パスは IPRA からスタートします。

(b) CA のサブジェクトの名称を制限する名称順序規則。

(c) PCA 概念の使用。この概念では、個々の PCA の知識を証明チェーン確認ロジックに組込む必要があります。個々の PCA の知識は、チェーンが正当であるかどうかを確認するために必要でした。

X.509 v3 では、RFC 1422 に示されている要求事項の多くは、証明書エクステンションを使用することで、使用される CA 構造を制限せずに満足できるので、特に、証明書ポリシーに関連する証明書エクステンションによって PCA が不要になり、制約エクステンションによって名称順序規則が不要になっています。このため、本文書はより柔軟性のある下記のアーキテクチャをサポートします。

(a) 証明書パスはユーザー自身のドメイン内の CA の公開鍵からも、階層の最上位の公開鍵からでもスタートすることができます。ユーザー自身のドメイン内の CA の公開鍵からスタートすればいくつかの利点が得られます。環境によっては、ローカル・ドメインが最も信用できます。

(b) 名称制約エクステンションを証明書中に明示的に含めることで名称制約を課すことができますが、これは強制ではありません。

(c) PCA 概念の代わりにポリシー・エクステンションとポリシー・マッピングが使用されるので自動化の度合いが一層高まります。アプリケーションは、PCAに対する事前の知識ではなく、証明書の内容に基づいて証明書パスが正しいかどうか判断できます。このため証明書チェーン処理を自動化できます。

3.3 取消し English

証明書は、発行されると有効期限内は使用できるのが普通です。しかし状況によっては有効期限が切れる前に証明書が無効になることもあります。このような状況としては、名称の変更、サブジェクトと CA との関係の変更 (たとえば従業員が退職するなど)、および対応する秘密鍵が改ざんされたか改ざんされた可能性がある場合などがあります。このような状況では、CA はその証明書を取消す必要があります。

X.509 は証明書を取消す一つの方法を定義しています。この方法では、各 CA は CRL と呼ばれる署名されたデータ構造を定期的に発行します。CRL は、CA が署名し、公開リポジトリィーで自由に利用できるようになっている、取消された証明書を識別するタイムスタンプ付きのリストです。CRL 中では、取消された証明書はそれぞれの証明書シリアル番号で識別されます。証明書を使用するシステムが(たとえばリモート・ユーザーのデジタル署名を確認するために)証明書を使用する場合、そのシステムは証明書の署名と有効性をチェックするだけでなく、十分に新しい CRL を取得してその証明書のシリアル番号がその CRL に載っていないことをチェックします。「十分に新しい (suitably-recent)」の意味はローカル・ポリシーによって変わりますが、普通は直近に発行された CRL を意味します。CA は定期的に (たとえば毎時、毎日、あるいは毎週) 新しい CRL を発行します。取消し通知が行われると、その後最初に発行される更新版CRLにエントリが追加されます。取消された証明書の有効期限が切れたときは、その後発行される定期 CRL に 1 回載せてから、エントリを CRL から削除することができます。

この取消し方法の利点は、CRL を証明書そのものと全く同じ手段、つまり信用のおけない通信およびサーバー・システムを介して配布できることです。

信用のおけない通信システムおよびサーバーを使用するこのCRL 取消し方法には、取消しの時間的細分性を CRL 発行間隔より細かくできないという制約があります。たとえば、今取消しが発表された場合、その取消しは次の定期 CRL が発行される (CAが CRL を発行する頻度によって 1 時間、1 日、あるいは 1 週間経過する)までは、証明書を使用するシステムに確実には通知されません。

X.509 v3 証明書フォーマットの場合と同様に、複数のベンダーから相互実装できるようにするためは、X.509 v2 CRL フォーマットはインターネットでの使用に適するよう方針決定される必要があります。しかし本方針は、CA に CRL を発行するよう強制はしていません。オンライン取消し通知をサポートするメッセージ・フォーマットとプロトコルは他の PKIX 仕様書中で定義することができます。環境によっては、オンラインで取消し通知を行う方法を X.509 CRL の代わりに使用できます。オンライン取消しチェックを採用すると、取消しの発表から、その情報を証明書使用システムへ配布するまでの時間的な遅れを大幅に短縮できます。CA が一旦その発表を真性かつ有効と認めれば、オンライン・サービスへの照会には、取消しが証明書の有効性に及ぼす影響が正しく反映されます。しかしこの方法では追加のセキュリティ要求事項が必要となります。つまり、リポジトリィーは信用できなくても構いませんが、証明書の確認者がオンライン確認サービスを信用しなければなりません。

3.4 運用プロトコル English

証明書を使用するクライアント・システムに証明書と CRL (あるいはステータス情報) を配信するために運用プロトコルが必要です。証明書と CRL を配信するには様々な手段があるので、それらの手段をサポートできるように、LDAP、HTTP、FTP および X.500 に基づいた配布手順などが必要です。これらの機能をサポートする運用プロトコルは PKIX 仕様書で定義されます。これらの仕様書には、メッセージ・フォーマットの定義と、適切な MIME コンテンツ・タイプの定義と参照などの、上記の運用環境のすべてをサポートする手順とを含めることができます。

3.5 管理プロトコル English

PKI ユーザーと管理エンティティとの間のオンライン・トランザクションをサポートするために管理プロトコルが必要です。たとえば、鍵ペアが関連付けられているクライアント・システムと CA との間に、あるいは相互に確認しあう CA 間に、管理プロトコルを使用することができます。管理プロトコルがサポートすべき機能としては次のものがあります。

(a) 登録: ユーザーが最初に自らの存在を (直接かあるいは RA を介して) CA に知らせるプロセスです。登録してからでないとその CA はそのユーザーに対して証明書を発行できません。

(b) 初期化: クライアント・システムのセキュアな運用を可能にするためには、インフラストラクチャのどこか別の場所に保管された鍵と適切に関連した鍵材料をインストールする必要があります。たとえば、クライアントは、証明書パスの確認に使用できるように、信用のおける CA の公開鍵などの保証された情報によってセキュアに初期化される必要があります。クライアントはまた、普通は自らの鍵ペアで初期化される必要があります。

(c) 証明: これは CA がユーザーの公開鍵について証明書を発行し、その証明書をユーザーのクライアント・システムに戻し、さらに (あるいは) その証明書をリポジトリィー中に掲示するプロセスです。

(d) 鍵ペア・リカバリ: オプションとして、ユーザー・クライアントの鍵材料 (たとえば暗号化に使用するユーザーの秘密鍵など) を CA あるいは鍵バックアップ・システムによってバックアップしてもらうことができます。これらのバックアップされた鍵をユーザーが必要とする場合は (たとえばパスワードを忘れたり鍵チェーン・ファイルを無くしたりして)、オンライン・プロトコルのやり取りが必要となります。

(e) 鍵ペア更新: すべての鍵は定期的に更新される必要があります。つまり、新しい鍵ペアと交換し、新しく証明書を発行してもらう必要があります。

(f) 取消しリクエスト: 権限のある人が、証明書の取消しを必要とするような異常な状態を CA に通知します。

(g) 相互証明: 相互証明書を作成するのに必要な情報を 2 つの CA が交換します。相互証明書は、ある CA から別の CA に対して発行される証明書で、証明書を発行するときに使用される CA 署名鍵が入っています。

オンライン・プロトコルだけが上記の機能を達成する方法ではないことに注意してください。すべての機能について、同じ結果をもたらすオフライン方法が存在します。また本仕様書はオンライン・プロトコルの使用を強制するものではありません。たとえばハードウェア・トークンを使用する場合には、機能の大部分はトークンを物理的に配達する過程で達成されます。また、いくつかの機能を一つにまとめて 1 回のプロトコル交換で達成できる場合もあります。特に、複数の登録、初期化、および証明機能を一つにまとめて 1 回のプロトコル交換で達成することができます。

将来発行されるPKIX シリーズの仕様書は、上記の機能をサポートする標準メッセージ・フォーマットの集まりを定義する可能性があります。そうなれば、これらのメッセージを異なった環境 (たとえばオンライン、電子メール、WWW) で伝達するためのプロトコルもそれらの仕様書の中で説明されることになります。

 

4 証明書と証明書エクステンション・プロファイル English

本セクションは、相互運用性を高め PKI を繰返し使用できるようにする公開鍵証明書の方針を説明しています。本セクションは、X.509 v3 証明書フォーマットと、[X. 509] で定義されている標準証明書エクステンションとに基づいています。ISO/IEC/ITU 文書は ASN. 1 の 1993 年バージョンを使用しています。本文書は 1988 ASN.1 シンタックスを使用していますが、エンコードされた証明書と標準エクステンションは同じです。本セクションはまたインターネット・コミュニティで PKI をサポートするときに必要となる秘密エクステンションも定義しています。

証明書は、広い範囲にわたって相互運用性の目標をカバーし、より広い範囲の運用および保証の要求事項をカバーする、様々なアプリケーションと環境で使用されることになります。本書の目的は、広い相互運用性と限定された特殊な要求事項との両方を必要とする一般的なアプリケーションについて、共通のベースラインを確立することにあります。特に、インフォーマルなインターネット電子メール、IPsec、および WWW アプリケーションを対象として、X.509 v3 証明書の使用をサポートすることに重点が置かれています。

4.1 基本的な証明書フィールド English

X.509 v3 証明書の基本的なシンタックスを下記に示します。署名計算用に、証明書は ASN. 1 区別化エンコード規則 (DER) [X.208] を使用してエンコードされます。ASN.1 DER エンコーディングは、各要素について、タグ、長さ、値をエンコードするシステムです。

Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
 
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version shall be v3 }

Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {
notBefore Time, notAfter Time }
 
Time ::= CHOICE {
utcTime UTCTime, generalTime GeneralizedTime }

UniqueIdentifier ::= BIT STRING

SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }

下記の項目は インターネットで使用される X.509 v3 証明書を説明しています。

4.1.1 証明書フィールド English

証明書は 3 つの必須フィールドから構成されるシーケンスです。これらのフィールドが下記のサブセクションで詳しく説明されています。

4.1.1.1 tbsCertificate English

このフィールドにはサブジェクトと発行人の名称、サブジェクトに関連した公開鍵、有効期限、その他の関連情報が入ります。詳しくはセクション 4.1.2 を参照してください。tbscertificate には 4.2 で説明されているエクステンションを含めることができます。

4.1.1.2 signatureAlgorithm English

signatureAlgorithm フィールドには、この証明書に署名する CA が使用する暗号化アルゴリズムの識別子が入ります。サポートされている署名アルゴリズムがセクション 7.2 に示されています。

アルゴリズム識別子は下記の ASN.1 構造によって定義されます。

AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }

アルゴリズム識別子は暗号化アルゴリズムを識別するのに使用されます。OBJECT IDENTIFIER コンポーネントがこのアルゴリズム (SHA-1 を有する DSAなど) を識別します。オプションのパラメータ・フィールドの内容は、識別されたアルゴリズムによって決まります。この仕様書でサポートされているアルゴリズムの一覧がセクション 7.2 に示されています。

このフィールドには、シーケンス tbsCertificate (セクション 4.1.2.3 を参照) 中の署名フィールドと同じアルゴリズムが入っていなければなりません。

4.1.1.3 signatureValue English

signatureValue フィールドには、ASN. 1 DER でエンコードされた tbsCertificate に基づいて計算されたデジタル署名が入ります。ASN.1 DER でエンコードされた tbsCertificate は、署名機能への入力として使用されます。この署名値は次に BIT STRING として ANS. 1 エンコードされ、証明書の署名フィールドに入れられます。このプロセスの詳細が、サポートされているアルゴリズムのそれぞれについてセクション 7.2 で規定されています。

この署名を生成することによって、CA は tbsCertificate フィールド中の情報の有効性を証明します。特に、CA は公開鍵材料と証明書のサブジェクトとの間の関連を証明します。

4.1.2 TBSCertificate English

シーケンス TBSCertificate には、証明書のサブジェクトと証明書を発行する CA とに関連する情報が入ります。それぞれの TBSCertificate には、サブジェクトと発行人の名称、サブジェクトに関連した公開鍵、有効期限、バージョン番号、およびシリアル番号が入ります。TBSCertificate によってはオプションの個別識別子フィールドが入ります。これらのフィールドのシンタックスとセマンティックスを以下で説明します。TBSCertificate にはエクステンションを入れることができます。インターネット PKI 用のエクステンションがセクション 4.2 で説明されています。

4.1.2.1 バージョン English

このフィールドはエンコードされた証明書のバージョンを記述します。本方針に沿ってエクステンションが使用されている場合は、X.509 バージョン 3 (値は 2) を使用してください。エクステンションではなくUniqueIdentifier (固有の識別子) が使用されている場合はバージョン 2 (値は 1) を使用してください。基本的なフィールドしか使用されていない場合はバージョン 1 (デフォルト値であるため証明書では値を指定しません) を使用してください。

どのバージョンの証明書でも受入れることができるように実装を準備してください。少なくとも、適合実装はバージョン 3 の証明書を認識できなければなりません。

この方針に基づいた実装は、バージョン 2 の証明書が作成されることを予期していません。

4.1.2.2 シリアル番号 English

シリアル番号は、CA が各証明書に割当てる整数です。シリアル番号は任意の CA が発行する証明書ごとに全部異なっていなければなりません (つまり発行人とシリアル番号とでどの証明書であるか識別できます)。

4.1.2.3 署名 English

このフィールドには CA が証明書に署名するときに使用するアルゴリズムの識別子が入ります。

このフィールドには、シーケンス証明書 (セクション 4.1.1.2 を参照) 中のsignatureAlgorithm フィールドにあるものと同じアルゴリズム識別子が入らなければなりません。オプションのパラメータ・フィールドの内容は、識別されたアルゴリズムによります。この仕様書がサポートしている署名アルゴリズムの一覧がセクション 7.2 に示されています。

4.1.2.4 発行人 English

発行人フィールドは、証明書に署名してその証明書を発行したエンティティを識別します。発行人フィールドには、空でない DN  を入れなければなりません。発行人フィールドは X.501 タイプの名称として定義されます。[X.501] 名は下記の ASN.1 構造によって定義されます。

Name ::= CHOICE { RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType

DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1.. MAX)),
bmpString BMPString (SIZE (1..MAX)) }

Name は、国名や国名に対応する値(たとえばUS)などの複数の属性から成る階層構造の名称を記述します。コンポーネント AttributeValue のタイプは AttributeType で示されます (通常は DirectoryString です)。

DirectoryString タイプは、PrintableString、TeletexString、BMPString、UTF8String、および UniversalStringのうちのいずれかとして定義されます。推奨されるエンコーディングはUTF8String エンコーディングです。2003 年 12 月 31 日より後に発行される証明書はすべてDirectoryString の UTF8String エンコーディングを使用しなければなりません (ただし下記を参照)。それまでは、適合 CA は DN を作成するとき、下記のオプションの中から選ぶ必要があります。これは CA 自身の名称にも該当します。

(a) 文字セットで十分であれば、ストリングは PrintableString として表すことができます。

(b) (a) に当てはまらない場合、BMPString 文字セットで十分であれば、ストリングは BMPString として表すことができます。

(c) (a) にも (b) にも当てはまらない場合は、ストリングは UTF8String として表さなければなりません。(a) か (b) に当てはまる場合でも、CA はUTF8String を選択できます。

2003 年 12 月 31 日より後に適用されるエンコーディング要求事項には、次の例外が認められています。

(a) CA は、UTF8String にスムーズに移行できるように、名称引継ぎ (name rollover) 証明書を発行することができます。そのような証明書には、発行人としての UTF8String エンコードされた CA の名称と、サブジェクトとしての従来の名称エンコーディング (あるいはその逆) が入ります。

(b) セクション 4.1.2.6 でも述べられているように、サブジェクト・フィールドには、エンコード方法には関係なく、サブジェクト CA が発行するすべての証明書について、発行人フィールドの内容に適合する空でない DN が入らなければなりません。

後方適合性を保証するために TeletexString と UniversalString が用意されています。これらのタイプは新規のサブジェクトの証明書には使用しないでください。しかし、これらのタイプは名称がすでに確定している場合の証明書には使用できます。証明書のユーザーはこれらのタイプの証明書を受取ることができるように準備をしておくべきです。

また、従来からの実装の多くは ISO 8859-1 文字セット (Latin1String) でエンコードされた名称をサポートしており、それらを TeletexString と呼んでいます。Latin1String は、西ヨーロッパの国々で使用されている、TeletexString 文字セットには含まれていない文字をも含んでいます。TeletexString を処理する実装は ISO 8859-1 文字セット [ISO 8859-1] を完全に処理できるようになっているべきです。

前述したように、 DN は属性から構成されます。本仕様書は名称に使用できる属性のタイプを制限するものではありませんが、適合実装は、下記に示す属性タイプから構成される名称の証明書を受取れるようになっていなければなりません。本仕様書はこれら以外の属性タイプにも対応していることを推奨しています。

標準的な属性セットが X.500 シリーズの仕様書 [X.520] で定義されています。本仕様書の実装は、発行人の名称として次の標準属性タイプを受取れるようになっていなければなりません: 国、組織、組織内ユニット、 DN 識別子、州あるいは地域の名称、および一般名 (Susan Housley など)。本仕様書の実装はまた、発行人の名称として次の標準属性タイプを受取れることが推奨されます: 住所、役職、姓、名、イニシャル、世代識別子 ("Jr."、"3rd"、"IV" など)。これらの属性タイプについてのシンタックスおよび関連するオブジェクト識別子 (OID) が、付録 A とB の ASN.1 モジュールに示されています。

本仕様書の実装はまた、[RFC 2247] で定義されている domainComponent 属性を受取れるようになっていなければなりません。ドメイン (ネームサーバ) システム (DNS) は階層構造の資源ラベリング・システムを提供しています。この属性は、DNS 名と並列して DN を使用したいと思っている組織に対して便利な手段を提供します。これは代替名称フィールドの dNSName コンポーネントの代わりになるものではありません。実装は、そのような名称を DNS 名に変換できる必要はありません。この属性タイプについてのシンタックスおよび関連するオブジェクト識別子 (OID) が、付録 A付録 B の ASN.1 モジュールに示されています。

証明書ユーザーは、証明書パス確認用に名称チェーニングを実行できるように (セクション 6 を参照)、発行人の DN とサブジェクトの DN  (セクション 4.1.2.6 を参照) の各フィールドを処理できるようになっていなければなりません。名称チェーニングは、ある証明書中の発行人の DN を、CA 証明書中のサブジェクトの名称と比較することで行われます。

本仕様書は、X.500 シリーズの仕様書で規定されている名称比較機能の一部のみを要求しています。適合実装に対する要求事項は次のとおりです。

(a) 異なったタイプとしてエンコードされている属性値 (PrintableString、BMPString など) は異なったストリングを表していると見なせること。

(b) PrintableString 以外のタイプの属性値では大文字と小文字の区別があること (これによって属性値をバイナリ・オブジェクトとして比較できます)。

(c) PrintableString タイプの属性値では大文字と小文字の区別がないこと (たとえば、"Marianne Swanson" と "MARIANNE SWANSON" は同じです)。

(d) PrintableString タイプの属性値は、先頭と末尾の空白を削除し、1 つあるいはそれ以上の連続する空白文字からなる内部のサブストリングを単一の空白に変換してから比較される。

これらの名称比較規則によって、証明書のユーザーは、自分のよく知らない言語あるいはエンコーディングを使って発行された証明書でも確認できます。

また、本仕様書の実装は、これらの比較規則を使用して、よく知らない属性タイプでも名称チェーニング処理できます。これによって、実装は発行人名称によく知らない属性があっても証明書を処理できるようになります。

X.500 シリーズの仕様書に規定されている比較規則では、 DN 中のデータのエンコードに使用される文字セットは関連性がないことになっています。つまり、エンコーディングとは関係無く、文字そのものが比較されます。本方針の実装は、X.500 シリーズで規定されている比較アルゴリズムを使用してもよいことになっています。そのような実装は、上記で規定されたアルゴリズムによって認識される名称マッチのスーパーセットを認識できることになります。

4.1.2.5 有効性  English

証明書の有効期限とは、その証明書のステータスについて CA が情報を維持することを保証する期間のことです。このフィールドは 2 つの日付のシーケンス (SEQUENCE) として表されます。2 つの日付とは、証明書の有効期限が始まる日付 (notBefore) と、有効期限が終わる日付 (notAfter) です。notBefore も notAfter も、UTCTime または GeneralizedTime としてエンコードできます。

本方針に適合する CA は、証明書の有効期限の日付を 2049 年までは UTCTime としてエンコードしなければなりません。2050 年以降の証明書の有効期限の日付は GeneralizedTime としてエンコードされなければなりません。

4.1.2.5.1 UTCTime English

標準時タイプ UTCTime は、現地時間だけでは十分でない国際アプリケーション向けの標準 ASN.1 タイプです。UTCTime では、年は下 2 桁で指定し、時刻は分単位あるいは秒単位の精度で指定します。UTCTime には Z (Zulu、つまりグリニッジ標準時) あるいは時差のいずれかが含まれます。

本方針では、UTCTime 値はグリニッジ標準時 (Zulu) で表さなければならず、たとえ 0 秒でも秒を省略してはなりません (つまり時刻は YYMMDDHHMMSSZ と表します)。適合システムは年フィールド (YY) を次のように解釈しなければなりません:

YY が 50 以上の場合は、年は 19YY と解釈されなければならず、

YY が 50 未満の場合は、年は 20YY と解釈されなければなりません。

4.1.2.5.2 GeneralizedTime English

一般的な時間タイプである GeneralizedTime は、可変精度時刻表示向けの標準 ASN.1 タイプです。オプションとして、GeneralizedTime フィールドには現地時間とグリニッジ標準時との時差を含めることができます。

本方針では、GeneralizedTime 値はグリニッジ標準時 (Zulu) で表さなければならず、たとえ 0 秒でも秒を省略してはなりません (つまり時刻は YYYYMMDDHHMMSSZ と表します)。GeneralizedTime 値は秒未満の時間を含んでいてはなりません。

4.1.2.6 サブジェクト  English

サブジェクト・フィールドは、サブジェクトの公開鍵フィールドに保存されている公開鍵に関連したエンティティを識別します。サブジェクト名は、サブジェクト・フィールドに入れることも、subjectAltName エクステンションに入れることもできます。サブジェクトが CA の場合 (たとえば、4.2.1.10 で説明されているように、基本制約エクステンションが存在していて、cA の値が TRUE の場合)、サブジェクト CA が発行するすべての証明書のサブジェクト・フィールドには発行人フィールドの内容に適合した、空でない DN  (セクション 4.1.2.4 を参照)が入らなければなりません。サブジェクトの名称情報が subjectAltName エクステンション中にしか存在しない場合は (たとえば電子メール・アドレスあるいはURIにしかバインドされていない鍵の場合)、サブジェクト名は空シーケンスでなければならず、subjectAltName エクステンションはクリティカルでなければなりません。

サブジェクト・フィールドが空でない場合は、サブジェクト・フィールドには X.500 に準拠した DN  (DN) が入っていなければなりません。DN は、発行人名フィールドで定義された CA が証明する各サブジェクト・エンティティについて固有でなければなりません。CA は同一のサブジェクト・エンティティに対して同一の DN を使用して複数の証明書を発行することができます。

サブジェクト名フィールドは X.501 タイプの名称として定義されます。このフィールドに対する実装要求事項は、発行人フィールドに対して定義されているものと同一です (セクション 4.1.2.4 を参照)。DirectoryString タイプの属性値をエンコードするときには、発行人フィールドに対するエンコード規則が適用されなければなりません。本仕様書の実装は、発行人フィールドに対して要求される属性タイプが入っているサブジェクト名を受入れることができるようになっていなければなりません。本仕様書の実装は、発行人フィールドに対して推奨される属性タイプが入っているサブジェクト名を受入れできることが望まれます。これらの属性タイプについてのシンタックスおよび関連するオブジェクト識別子 (OID) が、付録 A とB の ASN.1 モジュールに示されています。また、本仕様書の実装は、これらの比較規則を使用して、よく知らない属性タイプでも処理 (名称チェーニング処理)できます。これによって、実装はサブジェクト名によく知らない属性があっても証明書を処理できるようになります。

また、EmailAddress 属性としてサブジェクトの DN 中に RFC 822 名称が埋込まれているような従来の実装も存在します。EmailAddress の属性値は IA5String タイプで、PrintableString 文字セットには含まれていない @ 文字も使えます。EmailAddress 属性値は大文字と小文字を区別しません (たとえば"fanfeedback@redsox.com" は "FANFEEDBACK@REDSOX.COM" と同じです)。

電子メール・アドレス付きの証明書を新たに作成しようとする適合実装は、サブジェクトの代替名フィールド (セクション 4.2.1.7 を参照) に rfc822Name を使用することによってそのようなアイデンティティを記述しなければなりません。従来の実装をサポートする目的で、サブジェクトの DN 中にEmailAddress 属性を同時に含めることは、推奨はされませんが禁止されているわけではありません。

4.1.2.7 サブジェクトの公開鍵情報  English

このフィールドは公開鍵を伝達し、公開鍵が使用されるアルゴリズムを識別するのに使用されます。アルゴリズムはセクション 4.1.1.2 で規定されている AlgorithmIdentifier 構造を使用して識別されます。サポートされているアルゴリズムに関するオブジェクト識別子と、公開鍵材料 (公開鍵とパラメータ) をエンコードする方法とがセクション 7.3 に示されています。

4.1.2.8 固有の識別子 English

これらのフィールドはバージョンが 2 か 3 の場合にのみ現れます (セクション 4.1.2.1 を参照)。サブジェクトおよび/または発行人の名称が後で再使用される可能性を考えて、サブジェクトと発行人の固有の識別子が証明書に記載されます。本方針は、名称を異なったエンティティに再使用しないこと、およびインターネット証明書が固有の識別子を使用しないことを推奨しています。本方針に適合する CA は固有の識別子を使用する証明書を作成すべきではありません。本方針に適合するアプリケーションは、固有の識別子を調べて比較できることが推奨されます。

4.1.2.9 エクステンション English

このフィールドはバージョンが 3 の場合にのみ現れます (セクション 4.1.2.1 を参照)。このフィールドは 1 つあるいはそれ以上の証明書エクステンションのシーケンス (SEQUENCE) です。インターネット PKI 中の証明書エクステンションのフォーマットと内容はセクション 4.2 で定義されています。

4.2 標準証明書エクステンション English

X.509 v3 証明書用に定義されたエクステンションは、追加の属性をユーザーあるいは公開鍵に関連付ける方法と、証明階層を管理する方法を提供します。X.509 v3 証明書フォーマットを使用すると、コミュニティはコミュニティ独自の情報を伝達する秘密鍵を定義できます。証明書中の各エクステンションは、クリティカルと指定することもノンクリティカルと指定することもできます。証明書を使用するシステムは、認識できないクリティカル・エクステンションを発見した場合はその証明書を拒絶しなければなりません。しかし、ノンクリティカル・エクステンションは認識できなくても無視して構いません。下記のセクションでは、インターネット証明書内での使用が推奨されるエクステンションと参考文献を示します。コミュニティは追加のエクステンションを使用することを選ぶこともできますが、証明書にクリティカル・エクステンションを採用する場合にはコミュニティ以外で使用できない可能性もあるので十分注意が必要です。

各エクステンションには OID と ASN.1 の両方の構造が含まれています。エクステンションが証明書中にあると、OID はフィールド extnID として現れ、対応する ASN.1 エンコードされた構造はオクテット・ストリング extnValue の値となります。特定の証明書には特定のエクステンションの 1 つのインスタンスしか現れません。たとえば、証明書には 1 つの機関鍵識別子エクステンションしかないこともあります (セクション 4.2.1.1 を参照)。エクステンションにはブーリアン・クリティカルも含まれます。デフォルト値は FALSE です。各エクステンションのテキストは、クリティカル・フィールドに入れることのできる値を指定しています。

適合 CA は、鍵識別子 (セクション 4.2.1.14.2.1.2 を参照)、基本的な制約 (セクション 4.2.1.10 を参照)、鍵の用途 (セクション 4.2.1.3 を参照)、および証明書のポリシー (セクション 4.2.1.5 を参照) の各エクステンションをサポートしなければなりません。CA がサブジェクト・フィールドに空シーケンスが入った証明書を発行する場合は、CA はサブジェクトの代替名称エクステンション (セクション 4.2.1.7 を参照) をサポートしなければなりません。これ以外のエクステンションをサポートするかどうかは任意です。適合 CA は、本仕様書で識別されていないエクステンションをサポートしても構いませんが、証明書の発行人は、そのようなエクステンションをクリティカルとして指定すると相互運用性が失われる恐れがあることに注意しなければなりません。

最低限でも、本方針に適合するアプリケーションは、本仕様書に従えばクリティカルでなければならない、またはクリティカルであってもよいエクステンションを認識できなければなりません。これらのエクステンションは次のとおりです: 鍵の用途 (セクション 4.2.1.3 を参照)、証明書ポリシー (セクション 4.2.1.5 を参照)、サブジェクトの代替名称 (セクション 4.2.1.7 を参照)、基本的な制約 (セクション 4.2.1.10 を参照)、名称の制約 (セクション 4.2.1.11 を参照)、ポリシーの制約 (セクション 4.2.1.12 を参照)、および延長された鍵の用途 (セクション 4.2.1.13 を参照)。

さらに、本方針は、機関鍵識別子エクステンションおよびサブジェクト鍵識別子エクステンション(セクション 4.2.1.14.2.1.2 を参照) のアプリケーション・サポートを推奨しています。

4.2.1 標準エクステンション English

本セクションでは、インターネット PKI 向けに [X.509] で定義されている標準証明書エクステンションを示します。各エクステンションは [X.509] で定義されている OID と関連しています。これらの OID は、下記で定義される id-ce arc のメンバーです:

id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}

4.2.1.1 機関鍵識別子 English

機関鍵識別子エクステンションは、証明書の署名に使用される秘密鍵に対応する公開鍵を識別する手段を提供します。このエクステンションは発行人が署名用の鍵を複数個持っているとき (鍵ペアが複数個同時に存在するか切換えが行われた場合) に使用されます。鍵識別子 (発行人の証明書中のサブジェクトの鍵識別子) あるいは発行人の名称とシリアル番号に基づいて識別が行われます。

authorityKeyIdentifier エクステンションの keyIdentifier フィールドは、適合 CA がチェーン構築用に作成するすべての証明書中に含まれていなければなりません。ただし、CA が自らの公開鍵を「自己署名した」証明書として配布する場合には機関鍵識別子は省略できます。この場合、サブジェクト識別子と機関鍵識別子とは同じになります。

keyIdentifier フィールドの値は、証明書の署名の確認に使用される公開鍵から得られているか、あるいは固有の値を生成する方法によって得られていることが推奨されます。公開鍵から鍵識別子を生成するのによく使用される 2 つの方法がセクション 4.2.1.2 で説明されています。また固有の値を生成するのによく使用される方法がセクション 4.2.1.2 で説明されています。鍵識別子がまだ確立されていない場合は、これらの方法のいずれかを使用して keyIdentifiers を生成することが推奨されます。

本方針は、すべての証明書ユーザーが鍵識別子法をサポートすることを推奨しています。

このエクステンションはクリティカルと指定してはなりません。

id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

KeyIdentifier ::= OCTET STRING

4.2.1.2 サブジェクト鍵識別子 English

サブジェクト鍵識別子エクステンションは、特定の公開鍵を有する証明書を識別する手段を提供します。

チェーン構築を容易にするため、このエクステンションはすべての適合 CA 証明書中に存在しなければなりません。つまり、このエクステンションは、cA の値が TRUE の基本制約エクステンション (セクション 4.2.1.10 を参照) を含むすべての証明書中に存在しなければなりません。サブジェクトの鍵識別子の値は、この証明書のサブジェクトが発行した証明書の機関鍵識別子エクステンション (セクション 4.2.1.1 を参照) の鍵識別子フィールド中の値と同じでなければなりません。

CA 証明書の場合、サブジェクト鍵識別子は公開鍵から得られているか、あるいは固有の値を生成する方法によって得られていることが推奨されます。公開鍵から鍵識別子を生成するのによく使用される 2 つの方法は次のとおりです:

(1) keyIdentifier は、ビット・ストリング subjectPublicKey (タグ、長さ、未使用ビットの数を除く) の値を 160 ビット SHA-1 ハッシュした値から構成されます。

(2) keyIdentifier は、値 0100 の後に、ビット・ストリング subjectPublicKeyの値を SHA-1 ハッシュした値の下位 60 ビットが続いた、4 ビット・タイプのフィールドから構成されます。

固有の値を生成するのによく使用される方法は、一定の割合で順番に大きくなる整数を使用する方法です。

エンド・エンティティの証明書については、サブジェクト鍵識別子エクステンションは、アプリケーションで使用される特定の公開鍵が入った証明書を識別する手段を提供します。エンド・エンティティが複数の証明書を得ている場合、特にそれらを複数の CA から得ている場合、サブジェクト鍵識別子は特定の公開鍵が入っている証明書の集まりを迅速に識別する手段を提供します。アプリケーションがエンド・エンティティの証明書を正しく識別できるように、このエクステンションはすべてのエンド・エンティティ証明書中に含まれていることが推奨されます。

エンド・エンティティの証明書では、サブジェクト鍵識別子が公開鍵から得られていることが推奨されます。公開鍵から鍵識別子を作成するのによく使用される 2 つの方法が前述されています。

鍵識別子がまだ確立されていない場合は、これらの方法のいずれかを使用して keyIdentifiers を生成することが推奨されます。

このエクステンションはクリティカルと指定してはなりません。

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier

4.2.1.3 鍵用途 English

鍵用途エクステンションは、証明書中の鍵の目的 (暗号化、署名、証明書への署名など) を定義します。複数の用途に使用される鍵に制約を加えたい場合には用途制約を行うことができます。たとえば、RSA 鍵を署名専用にしたい場合は、digitalSignature および/または nonRepudiation ビットを有効にします。同様に、RSA 鍵を鍵管理専用にしたい場合は、keyEncipherment ビットを有効にします。このエクステンション (使用される場合) はクリティカルに指定することが推奨されます。

id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }

KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }

KeyUsage タイプ中のビットは次のように使用します:

digitalSignature ビットは、否認防止 (ビット 1)、証明書への署名 (ビット 5)、あるいは取消し情報への署名 (ビット 6)を除くセキュリティ・サービスをサポートするために、サブジェクト公開鍵をデジタル署名目的で使用するときに有効にします。デジタル署名は、確実にエンティティあるいはデータ源を認証したい場合によく使用されます。

nonRepudiation ビットは、署名するエンティティが誤って何らかのアクション (証明書あるいは CRL 署名を除く) を拒絶することがないように否認防止サービスを提供する目的で使用されるデジタル署名を確認するためにサブジェクト公開鍵を使用するときに有効にします。

keyEncipherment ビットは、鍵を配達する目的でサブジェクト公開鍵を使用するときに有効にします。たとえば、鍵管理用に RSA 鍵を使用するときはこのビットを有効にしなければなりません。

dataEncipherment ビットは、暗号鍵ではなく、サブジェクト公開鍵を使用してユーザー・データを暗号化するときに有効にします。

keyAgreement ビットは、鍵合致にサブジェクト公開鍵を使用するときに有効にします。たとえば、鍵合致に Diffie-Hellman 鍵を使用する場合はこのビットを有効にしなければなりません。

keyCertSign ビットは、サブジェクト公開鍵を使用して証明書の署名を確認するときに有効にします。このビットは CA 証明書についてのみ有効にできます。

cRLSign ビットは、サブジェクト公開鍵を使用して取消し情報 (CRL など) の署名を確認するときに有効にします。

encipherOnly ビットの意味は、keyAgreement ビットが存在しないときは未定義となります。encipherOnly ビットが有効で、keyAgreement ビットも設定されている場合は、サブジェクト公開鍵は鍵合致を行っている間はデータの暗号化にのみ使用できます。

decipherOnly ビットの意味は、keyAgreement ビットが存在しないときは未定義となります。decipherOnly ビットが有効で、keyAgreement ビットも設定されている場合は、サブジェクト公開鍵は鍵合致を行っている間はデータの復号化にのみ使用できます。

本方針は KeyUsage エクステンション用に設定することのできるビットの組合わせを制限するものではありません。特定のアルゴリズムについて使用することのできる keyUsage エクステンションの値がセクション 7.3 に示されています。

4.2.1.4 秘密鍵有効期限 English

本方針はこのエクステンションを使用しないことを推奨します。本方針に適合する CA は、クリティカルと指定された秘密鍵有効期限エクステンション付きの証明書を作成してはなりません。

秘密鍵有効期限エクステンションを使用すると、証明書の発行人は証明書とは異なった有効期限を秘密鍵に指定できます。このエクステンションはデジタル署名鍵に使用されることを目的としています。このエクステンションは notBefore と notAfter の 2 つの任意コンポーネントから構成されます。証明書に関連する秘密鍵は、notBefore コンポーネントで示される時期より前、あるいは notAfter コンポーネントで示される時期より後にオブジェクトの署名用に使用されるべできはありません。本方針に適合する CA は、この 2 つのコンポーネントの少なくとも一方が存在しない限り、秘密鍵有効期限エクステンション付きの証明書を作成してはなりません。

notBefore と notAfter は (使用された場合) GeneralizedTime として表され、セクション 4.1.2.5.2 の定義に従って規定され解釈されなければなりません。

id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }

PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL }

4.2.1.5 証明書ポリシー English

証明書ポリシー・エクステンションには、一つまたはそれ以上のポリシー情報条項からなるシーケンスが入ります。それぞれのポリシー情報条項はオブジェクト識別子 (OID) とオプションの修飾子から構成されます。これらのポリシー情報条項は、証明書を発行するにあたってのポリシーと、証明書の使用目的を示すものです。オプションの修飾子を使用することもできますが、ポリシーの定義を変更するのに使用されるべきではありません。

特定のポリシー要求事項を有するアプリケーションは、受入れることができるポリシーの一覧を有し、証明書中のポリシー OID をその一覧と比較すべきです。このエクステンションがクリティカルに指定されている場合は、経路確認ソフトウェアは、このエクステンション (オプションの修飾子も含めて) を解釈することができるか、あるいは解釈できないのであればその証明書を拒絶するかしなければなりません。

相互運用性を高めるため、本方針は、ポリシー情報条項が OID のみから構成されることを推奨しています。OID だけでは不十分な場合でも、本仕様書に示されている修飾子のみを使用することを強く推奨しています。

本仕様書は、ポリシー作成者および証明書発行人が使用すべき 2 つのタイプのポリシー修飾子を定義しています。この 2 つのタイプとは、CPS ポインターとユーザー通知です。

CPS ポインター修飾子には、CA が発行する Certification Practice Statement (CPS) を指定するポインターが入ります。このポインターは URI 形式です。

ユーザー通知は、証明書が使用されるときに、必要とする側に対して表示されます。アプリケーション・ソフトウェアは、使用される証明書パス中のすべての証明書に含まれる、すべてのユーザー通知を表示すべきです。ただし、ユーザー通知がコピーされる場合は 1 つのコピーを表示するだけで十分です。そのような重複を避けるため、この修飾子は、エンド・エンティティ証明書中と、他の組織に対して発行された CA 証明書中にのみ存在すべきです。

ユーザー通知には、 noticeRef とexplicitText の 2 つの任意フィールドがあります。

noticeRef は (使用された場合)、組織の名称を示し、その組織によって作成された特定のテキスト・ステートメントを番号で識別します。たとえば、このフィールドは組織"CertsRUs" を識別し、番号 1 を通知します。一般的な実装の場合、アプリケーション・ソフトウェアは、CertsRUs の現行の通知セットが入った通知ファイルを有しています。アプリケーションはそのファイルから通知テキストを抽出して表示します。メッセージは、ソフトウェアがその環境に合わせて特定の言語メッセージを選択できるように複数の言語で書かれていても構いません。

explicitText フィールドには証明書中に直接入るテキスト・ステートメントが入ります。 explicitText フィールドはサイズが最大 200 文字のストリングです。

noticeRef と explicitText の両方のオプションが一つの修飾子中に含まれていて、noticeRef で示される通知テキストの場所をアプリケーション・ソフトウェアが認識できる場合は、そのテキストが表示されるべきです。そうでない場合は、explicitText ストリングが表示されるべきです。

id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }

certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }

-- インターネット・ポリシー修飾子用のpolicyQualifierIds

id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }

PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

Qualifier ::= CHOICE {
cPSuri CPSuri, userNotice UserNotice }

CPSuri ::= IA5String

UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
 
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
 
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }

4.2.1.6 ポリシー・マッピング English

このエクステンションは CA 証明書中で使用されます。ポリシー・マッピング・エクステンションは一つあるいはそれ以上の OID ペアを一覧表示します。各ペアはissuerDomainPolicy と subjectDomainPolicy から成ります。各ペアは、発行側の CA が自らの issuerDomainPolicy とサブジェクト側の CA のsubjectDomainPolicy を同等であると見なすことを示しています。

発行側 CA ユーザーは、アプリケーションによっては issuerDomainPolicy を受入れることができます。ポリシー・マッピングは、発行側 CA ユーザーが受入れたポリシーに対して、サブジェクト側の CA と関連するどのポリシーが対応しているかを発行側 CA ユーザーに連絡します。

このエクステンションは CA および/またはアプリケーションによってサポートされても構いませんが、ノンクリティカルでなければなりません。

id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }

4.2.1.7 サブジェクト代替名称 English

サブジェクト代替名称エクステンションを使用すると、証明書のサブジェクトに対してさらに別のアイデンティティをバインドできます。定義されているオプションとしては、インターネット電子メール・アドレス、DNS 名、IP アドレス、およびユニフォーム・リソース識別子 (URI) があります。完全にローカルな定義も含めて、まだ他にもオプションがあります。名称形式もいくつかあり、それぞれの名称形式は複数の値をとることができます。そのようなアイデンティティを証明書にバインドするときは、いつでもサブジェクト代替名称 (あるいは発行人代替名称) エクステンションを使用しなければなりません。

サブジェクト代替名称は明確に公開鍵にバインドされていると見なされるので、サブジェクト代替名称のすべての部分が CA によって確認されなければなりません。

また、証明書に含まれている唯一のサブジェクト・アイデンティティが代替名称形式 (たとえば電子メール・アドレス) の場合は、サブジェクトの DN は空白 (空シーケンス) でなければならず、また subjectAltName エクステンションが存在していなければなりません。サブジェクト・フィールドに空シーケンスが入っている場合は、subjectAltName エクステンションはクリティカルに指定されていなければなりません。

subjectAltName エクステンションにインターネット・メール・アドレスが入っている場合は、そのアドレスは rfc822Name フォーマットでなければなりません。rfc822Name フォーマットは RFC 822 [RFC 822] で定義された "addr-spec" です。addr-spec の形式は "local-part@domain" です。addr-spec の前にはフレーズ (一般名など) がなく、その後にはコメント (括弧でくくられたテキスト) がなく、さらに全体が "<" と ">" でくくられていないことに注意してください。また、RFC 822 addr-spec では大文字も小文字も使用できますがその区別はされないことに注意してください。

subjectAltName エクステンションに iPAddress が入っている場合は、そのアドレスは RFC 791 [RFC 791] で規定されているように "ネットワーク・バイト・オーダー"でオクテット・ストリング中に保存されていなければなりません。各オクテットの最下位ビット (LSB) はネットワーク・アドレス中の対応するバイトの LSB です。RFC 791 で規定されている IP バージョン 4 については、オクテット・ストリングは正確に 4 個のオクテットを有していなければなりません。RFC 1833 で規定されている IP バージョン 6 については、オクテット・ストリングは正確に 16 個のオクテットを有していなければなりません [RFC 1883]。

subjectAltName エクステンションにドメイン・ネーム・サービス・ラベルが入っている場合は、ドメイン名は dNSName (IA5String 形式) 中に保存されていなければなりません。ドメイン名は、RFC 1034 [RFC 1034] で規定されているように "好ましい名称シンタックス (preferred name syntax)" で表されていなければなりません。ドメイン名には大文字も小文字も使用できますがその区別はされないことに注意してください。また、ストリング " " はドメイン名には使用できますが、subjectAltName エクステンションで dNSName を " " にすることはできません。さらに、インターネット・メール・アドレスに DNS 表示を使用する (たとえば、wpolk@nist.gov の代わりにwpolk.nist.gov を使用する) ことはできません。そのようなアイデンティティは rfc822Name としてエンコードされます。

subjectAltName エクステンションに URI が入っている場合は、その名称が uniformResourceIdentifier (IA5String 形式) 中に保存されていなければなりません。名称は無関連 (non-relative) URL でなければならず、[RFC 1738] で規定されている URL シンタックスとエンコード規則に従っていなければなりません。名称はスキーム ("http"、"ftp"など) とスキーム固有の部分の両方を含んでいなければなりません。スキーム固有の部分は、ホストとして完全に記述されたドメイン名か IP アドレスを含んでいなければなりません。

[RFC 1738] で規定されているように、スキーム名には大文字と小文字の区別がありません (たとえば "http" と "HTTP" は同じです)。 ホスト部分は大文字と小文字の区別がありませんが、スキーム固有の部分の他のコンポーネントは大文字と小文字を区別しても構いません。URI を比較する場合は、適合実装は大文字と小文字を区別せずにスキームとホストを比較しなければなりませんが、スキーム固有の部分の残りは大文字と小文字の区別があるものと想定しなければなりません。

サブジェクト代替名称には、サブジェクトの DN と同様に、セクション 4.2.1.11 で説明されている名称制約エクステンションを使用して何らかの制約を加えることができます。

subjectAltName エクステンションが使用されている場合は、シーケンスには少なくとも一つのエントリがなければなりません。サブジェクト・フィールドとは異なって、適合 CA は、GeneralName フィールドが空になっている subjectAltNames 付きの証明書を発行してはなりません。たとえば、rfc822Name が IA5String として表されている場合、空ストリングは正しい IA5String ですが、そのような rfc822Name は本方針では許可されません。クライアントが証明書パスを処理するときにそのような証明書に遭遇した場合のクライアントの挙動は本方針では定義されていません。

また、ワイルドカード文字 (たとえば名称の集まりのためのプレースホルダー) を含むサブジェクト代替名称のセマンティックスは本仕様書では規定されていません。特定の要求事項を有するアプリケーションはそのような名称を使用することはできますが、その場合はセマンティックスを定義しなければなりません。

id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER}

OtherName ::= SEQUENCE {

type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }

4.2.1.8 発行人代替名称 English

4.2.1.7 の場合と同様に、本エクステンションはインターネット・スタイルのアイデンティティを証明書の発行人と関連付けるのに使用されます。発行人代替名称は 4.2.1.7 で規定されているようにエンコードされなければなりません。

本エクステンションは (使用される場合)クリティカルとして指定されるべきではありません。

id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }

IssuerAltName ::= GeneralNames

4.2.1.9 サブジェクト・ディレクトリ属性 English

サブジェクト・ディレクトリ属性エクステンションは、本方針の不可欠な要素としては推奨されませんが、ローカル環境では使用できます。本エクステンションはノンクリティカルでなければなりません。

id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

4.2.1.10 基本的制約 English

基本的制約エクステンションは、証明書のサブジェクトが CA かどうか、およびその CA 中の証明書パスがどのくらい深いかを示します。

pathLenConstraint フィールドは、cA が TRUE に設定されている場合にのみ意味を持ちます。このとき本フィールドは、この証明書のあと証明書パス中に最大で何部 CA 証明書を入れることができるかを示します。値がゼロであると、これ以後、証明書パスにはエンド・エンティティ証明書しか入れることができません。本フィールドが存在する場合は、pathLenConstraint フィールドの値はゼロ以上でなければなりません。pathLenConstraint フィールドが表示されない場合は、証明書パスの長さは無制限です。

本エクステンションはすべての CA 証明書中でクリティカル・エクステンションとして表示されなければなりません。本エクステンションはエンド・エンティティ証明書中に現れるべきではありません。

id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }

BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }

4.2.1.11 名称制約 English

名称制約エクステンションは CA 証明書中でしか使用してはなりません。本エクステンションは、証明書パス中の後続の証明書において、すべてのサブジェクト名が入るべき名称スペースを示します。制約はサブジェクトの DN あるいはサブジェクト代替名称に適用されます。制約は指定された名称形式が存在する場合にのみ適用されます。指定された形式の名称が証明書中に存在しない場合はその証明書は受入れられます。

制約は許可されるか除外される名称サブツリーとして定義されます。excludedSubtrees フィールド中の制約に合致する名称は、permittedSubtrees にどのような情報が入っていようとも無効です。このエクステンションはクリティカルでなければなりません。

本方針では、いかなる名称形式についても最小および最大フィールドは使用されていません。このため、最小は常にゼロで最大は常に存在しません。

URI については、制約は名称のホスト部分に適用されます。名称制約では、"foo.bar.com" や ".xyz.com" などのように、ホストまたはドメインを指定できます。制約がピリオドで始まる場合は、一つあるいはそれ以上のサブドメインを付けて拡張することができます。つまり、制約が ".xyz.com" の場合、abc.xyz.com と abc.def.xyz.com の両方がこれに合致します。しかし "xyz.com"は".xyz.com" に合致しません。制約がピリオドで始まっていない場合はホストを指定します。

インターネット・メール・アドレス用の名称制約では、特定のメールボックス、特定のホストの全アドレス、あるいは特定のドメイン中の全メールボックスを指定できます。特定のメールボックスを示す場合は、制約は完全なメール・アドレスとなります。たとえば、"root@xyz.com" はホスト "xyz.com" 上のルートのメールボックスを示します。特定のホスト上の全インターネット・メール・アドレスを示すには、制約をホスト名として指定します。たとえば制約 "xyz.com" には、その"xyz.com" ホストのいずれのメール・アドレスでも合致します。ドメイン中の任意のアドレスを指定するには、URI の場合と同様に先頭にピリオドを付けて制約を指定します。たとえば、".xyz.com" は "xyz.com" ドメイン中の全インターネット・メール・アドレスを示しますが、"xyz.com" ホスト上のインターネット・メール・アドレスは除外されます。

DNS 名制約は foo.bar.com として表します。どのサブドメインもこの名称制約に合致します。たとえば、www.foo.bar.com はこの制約に合致しますが、bigfoo.bar.com はこの制約に合致しません。

従来の実装の中には、サブジェクトの DN において、タイプ EmailAddress の属性にRFC 822 名が埋込まれたものがありました (セクション 4.1.2.6 を参照)。rfc822 名が制約されているにもかかわらず、証明書中にサブジェクト代替名称が無い場合は、サブジェクトの DN 中のタイプ EmailAddress の属性にrfc822 名制約を適用しなければなりません。EmailAddress 用の ASN.1 シンタックスとそれに対応する OID が付録 A と B に示されています。

形式 directoryName の制約は、証明書中のサブジェクト・フィールドと、directoryName タイプの subjectAltName エクステンションに適用されなければなりません。形式 x400Address の制約は、形式 x400Address の subjectAltName エクステンションに適用されなければなりません。

実装は、形式 directoryName の制約を適用するときは DN 属性を比較しなければなりません。最低限でも、実装はセクション 4.1.2.4 に規定されている DN 比較規則を実行しなければなりません。形式 directoryName の制約の付いた証明書を発行する CA は、完全な ISO DN 名比較アルゴリズムが実行されると期待すべきではありません。つまり、名称制約は、サブジェクト・フィールドか subjectAltName エクステンション中で使用されているエンコーディングと同様に記述されていなければなりません。

iPAddress のシンタックスはセクション 4.2.1.7 で説明したとおりに記述されていなければならず、特に名称制約については下記の追加を有していなければなりません。IPv4 アドレスについては、generalName の ipAddress フィールドが、アドレス範囲を表すために RFC 1519 (CIDR) のスタイルでエンコードされた 8 つのオクテットを有していなければなりません [RFC 1519]。IPv6 アドレスについては、ipAddress フィールドが、同様にエンコードされた 32 のオクテットを有していなければなりません。たとえば、クラス C のサブネット 10.9.8.0 用の名称制約は、オクテット 0A 09 08 00 FF FF FF 00 として表されなければなりません。このオクテットは CIDR 表記法では 10.9.8.0/255.255.255.0 となります。

本仕様書は、otherName、ediPartyName、および registeredID 用の名称制約についてシンタックスとセマンティックスを定義していません。

id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }

NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)

4.2.1.12 ポリシー制約 English

CA に対して発行される証明書にはポリシー制約エクステンションを使用することができます。ポリシー制約エクステンションは、2 つの方法で経路確認を制約します。本エクステンションは、ポリシー・マッピングを禁止するのに使用することも、経路中の各証明書が正しいポリシー識別子を有するようにと要求するのに使用することもできます。

inhibitPolicyMapping フィールドが存在する場合は、フィールドの値は、ポリシー・マッピングが禁止されるまで経路中に現れてもよい追加の証明書の数を示します。たとえば、この値が 1 であれば、この証明書のサブジェクトが発行した証明書ではポリシー・マッピングの処理が可能ですが、経路中の追加証明書では処理できません。

requireExplicitPolicy フィールドが存在する場合は、以降の証明書は正しいポリシー識別子を有していなければなりません。requireExplicitPolicy の値は、明確なポリシーが要求されるようになるまで経路中に現れてもよい追加の証明書の数を示します。正しいポリシー識別子とは、証明書パスのユーザーが要求するポリシーの識別子か、あるいはポリシー・マッピングで同等であると宣言されたポリシーの識別子です。

適合 CA はポリシー制約が空シーケンスであるような証明書を発行してはなりません。つまり、少なくとも inhibitPolicyMapping か requireExplicitPolicy のいずれかのフィールドが存在しなければなりません。空のポリシー制約に遭遇した場合のクライアントの挙動は本方針では規定されていません。

本エクステンションはクリティカルでもノンクリティカルでも構いません。

id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }

PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

4.2.1.13 拡張鍵用途フィールド English

本フィールドは、鍵用途エクステンション・フィールド中に示されている基本目的に追加されるかあるいはそれに取って代わる、証明された公開鍵の 1 つあるいはそれ以上の使用目的を示します。本フィールドは次のように定義されます:

id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

鍵の目的はそれを必要とするどの組織でも定義できます。鍵の目的を示すのに使用されるオブジェクト識別子は、IANA あるいは ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1 に従って割当てられなければなりません。

証明書の発行人の判断で、本エクステンションはクリティカルとすることもノンクリティカルとすることもできます。

本エクステンションをクリティカルに指定した場合は、その証明書は、示されたいずれかの目的にのみ使用しなければなりません。

本エクステンションをノンクリティカルに指定した場合は、そのエクステンションは鍵の本来の目的を示すだけであり、複数の鍵/証明書を有するエンティティの正しい鍵/証明書を見つける際に使用できます。本フィールドは勧告フィールドであり、認証機関が鍵の用途を本来の目的に限定していることを意味するものではありません。しかし、証明書を使用するアプリケーションが、その証明書を自らにとって受け入れ可能にするため、特定の目的を示すよう要求することは可能です。

証明書に、クリティカルな鍵用途フィールドとクリティカルな拡張鍵用途フィールドの両方が入っている場合は、両方のフィールドは別個に処理されなければならず、その証明書は両方のフィールドに矛盾しない目的に限って使用されなければなりません。両方のフィールドに矛盾しない目的がない場合は、その証明書はいかなる目的にも使用してはなりません。

本方針が定義する鍵用途の目的は次のとおりです:

id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1}
-- TLS Web サーバー認証
-- 矛盾しない鍵用途ビット: digitalSignature、
-- keyEncipherment あるいは keyAgreement
--
id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2}
-- TLS Web クライアント認証
-- 矛盾しない鍵用途ビット: digitalSignature および (または)
-- keyAgreement
--
id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3}
-- ダウンロード可能な実行可能コードの署名
-- 矛盾しない鍵用途ビット: digitalSignature
--
id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4}
-- 電子メール保護 -- 矛盾しない鍵用途ビット: digitalSignature、
-- nonRepudiation および/または (keyEncipherment
-- または keyAgreement)
--
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- オブジェクトのハッシュを、合意された時間ソースからある時間にバインドする。
-- 矛盾しない鍵用途ビット: digitalSignature、
-- nonRepudiation

4.2.1.14 CRL 配布ポイント English

CRL 配布ポイント・エクステンションは、CRL 情報がどのように得られるかを示します。本エクステンションはノンクリティカルにすべきですが、本方針は、CA および アプリケーションが本エクステンションをサポートすることを推奨しています。CRL 管理の詳細についてはセクション 5 を参照してください。

cRLDistributionPoints エクステンションに URI タイプの DistributionPointName が入っている場合は、次のセマンティックスが想定されなければなりません: URI は関連する理由で現行の CRL を示すポインターであり、関連する cRLIssuer によって発行される。URI の正しい値は 4.2.1.7 で定義されている値です。本仕様書は他の値については処理規則を定義していません。distributionPoint に理由が示されていない場合は、CRL には無条件取消しが入っていなければなりません。distributionPoint に cRLIssuer が示されていない場合は、CRLはその証明書を発行した CA が発行しなければなりません。

id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }

cRLDistributionPoints ::= { CRLDistPointsSyntax }

CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
 
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
 
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6) }

4.2.2 プライベート・インターネット・エクステンション English

本セクションは、インターネット公開鍵インフラストラクチャ (インターネット PKI) で使用される一つの新しいエクステンションを定義しています。本エクステンションは、発行側の CA をサポートするオンライン確認サービスをアプリケーションに識別させるのに使用できます。得られる情報は様々な形式なので、各エクステンションは、それぞれが URI を表すいくつかの IA5String 値のシーケンスとなっています。URI は、情報の場所とフォーマットおよびその情報を得るための方法を暗に指定します。

オブジェクト識別子が本プライベート・エクステンション用に定義されます。プライベート・エクステンションに関連したオブジェクト識別子は、id-pkix 名のスペース内の arc id-pe の下で定義されます。インターネット PKI 用に将来定義されるエクステンションも arc id-pe の下で定義されることになります。

id-pkix OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }

4.2.2.1 機関情報アクセス English

機関情報アクセス・エクステンションは、それが入っている証明書の発行人についての CA 情報とサービスにアクセスする方法を示します。情報とサービスには、オンライン確認サービスと CA ポリシー・データが含まれます (CRL の場所は本エクステンションでは規定されていません。その情報は cRLDistributionPoints エクステンションが提供します)。本エクステンションはサブジェクトあるいは CA 証明書中に含めることができますが、ノンクリティカルでなければなりません。

id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

AuthorityInfoAccessSyntax シーケンス中の各エントリは、本エクステンションが入っている証明書を発行した CA に関する追加情報のフォーマットと場所を記述しています。この情報のタイプとフォーマットは accessMethod フィールドで指定され、この情報の場所はaccessLocation フィールドで指定されます。この情報を取出す機構は accessMethod で暗示するか accessLocation で指定することができます。

本方針は accessMethod について一つの OID を定義しています。id-ad-caIssuers OID は、このエクステンションが入っている証明書を発行した CA より上位に位置する、証明書を発行した CA の一覧を追加情報に含めるときに使用します。ここで指定された CA 発行人記述は、証明書のユーザーが信用できる点で終端する証明書パスを選択しやすくすることを目的としています。

id-ad-caIssuers が accessInfoType として現れている場合は、accessLocation フィールドは、指定された記述サーバーと、その指定された記述を得るためのアクセス・プロトコルを記述します。accessLocation フィールドは、いくつかの形式をとる GeneralName として定義されます。情報が http、ftp、あるいは ldap を介して入手できる場合は、accessLocation はuniformResourceIdentifier でなければなりません。情報が ディレクトリ・アクセス・プロトコル (dap) を介して入手できる場合は、accessLocation は directoryName でなければなりません。情報が電子メールを介して入手できる場合は、accessLocation は rfc822Name でなければなりません。accessLocation の他の名称形式 (accessMethod が id-ad-caIssuers の場合) については、本仕様書ではセマンティックスが定義されていません。

他の PKIX 仕様書中で、追加のアクセス記述子が定義されていても構いません。

5 CRL と CRL エクステンションの方針 English

前述したように、この X.509 v2 CRL の方針の一つの目標は、相互運用可能で再使用可能なインターネット PKI の創出を助けることです。この目標を達成するため、このエクステンションの使い方のガイドラインが示され、このCRL に含まれている情報の性質についていくつかの前提が設けられています。

CRL は、様々な相互運用目標と、さらに多様な運用上および保証上の要求事項をカバーする、広範なアプリケーションと環境で使用できます。本方針は、広い相互運用性を必要とする一般的なアプリケーションについて共通のベースラインを確立するものです。本方針は各 CRL 中に存在すると予想される基本的な情報の集まりを定義しています。本方針はまた、頻繁に使用される属性用の CRL 内の共通の場所、およびこれらの属性用の共通表現を定義しています。

本方針はプライベートなインターネット CRL エクステンションあるいは CRL エントリ・エクステンションは定義していません。

追加要求事項あるいは特殊要求事項が設けられている環境は、本方針に基づいて構築することも、本方針の代わりに使用することもできます。

適合 CA は、他の取消し機構あるいは証明書ステータス機構が設けられていれば、CRL を必ずしも発行する必要はありません。CRL を発行する適合 CAはバージョン 2 の CRL を発行しなければならず、次に CRL を発行する日付を nextUpdate フィールド (セクション 5.1.2.5 を参照)、CRL 番号エクステンション (セクション 5.2.3 を参照)、および機関鍵識別子エクステンション (セクション 5.2.1 を参照) に含めなければなりません。適合アプリケーションはバージョン 1 と 2 の CRL を処理できなければなりません。

5.1 CRL フィールド English

X.509 v2 CRL シンタックスは次のとおりです。署名計算については、署名されるデータは ASN.1 DER エンコードされたデータです。ASN.1 DER エンコーディングは、各エレメントについてのタグ、長さ、値のエンコーディング・システムです。

CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
 
TBSCertList ::= SEQUENCE {
version Version OPTIONAL,
-- if present,
shall be v2 signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, shall be v2 } OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present,
shall be v2 }

-- バージョン、時間、CertificateSerialNumber およびエクステンションは
-- すべて ASN.1 を使用してセクション 4.1 で定義されています。

-- AlgorithmIdentifier はセクション 4.1.1.2 で定義されています。

下記の項目はインターネット PKI でのX.509 v2 CRL の使い方を示しています。

5.1.1 CertificateList フィールド  English

CertificateList は 3 つの必須フィールドが集まったシーケンスです。これらのフィールドは下記のサブセクションで詳しく説明されています。

5.1.1.1 tbsCertList  English

このシーケンスの最初のフィールドは tbsCertList です。このフィールド自体もシーケンスで、発行人名、発行日、次のリストの発行日、取消された証明書のリスト、およびオプションの CRL エクステンションから構成されています。取消された証明書のリストに示される各エントリは、ユーザー証明書シリアル番号、取消し日、およびオプションの CRL エントリ・エクステンションからなるシーケンスによって定義されます。

5.1.1.2 signatureAlgorithm  English

signatureAlgorithm フィールドには、CertificateList に署名するときに CA が使用するアルゴリズムのアルゴリズム識別子が入ります。このフィールドは AlgorithmIdentifier (セクション 4.1.1.2 で定義されています) タイプです。本仕様書でサポートされているアルゴリズムの一覧がセクション 7.2 に示されています。適合 CA は、サポートされている署名アルゴリズムを使用して署名するときには、セクション 7.2 に示されているアルゴリズム識別子を使用しなければなりません。

このフィールドには、tbsCertList シーケンス中の署名フィールドと同じアルゴリズム識別子が入らなければなりません (セクション 5.1.2.2 を参照)。

5.1.1.3 signatureValue English

signatureValue フィールドには、ASN.1 DERでエンコードされた tbsCertList に基づいて計算されたデジタル署名が入ります。ASN.1 DERでエンコードされた tbsCertListは、署名ファンクションに対する入力として使用されます。この署名値は、ビット・ストリングとして ASN.1 エンコードされ、CRL の signatureValue フィールドに入れられます。サポートされているアルゴリズム別に、本プロセスがセクション 7.2 で詳しく説明されています。

5.1.2 署名予定 (To Be signed) の証明書リスト English

署名予定の証明書リスト TBSCertList は、必須フィールドと任意フィールドからなるシーケンスです。必須フィールドは、CRL の発行人、CRL に署名するのに使用されたアルゴリズム、CRL が発行された日時、および CA が次の CRL を発行する日時を示します。

任意フィールドには、取消された証明書のリストと CRL エクステンションが入ります。取消された証明書のリストは、CA が発行した有効期限内の証明書を CA が一切取消していない場合をサポートするために、オプションとなっています。本方針に適合する CA は、発行されたすべての CRL について CRL エクステンション cRLNumber を使用しなければなりません。

5.1.2.1 バージョン  English

この任意フィールドは、エンコードされた CRL のバージョンを記述します。本方針に従ってエクステンションが使用されるときは、本フィールドが存在していてバージョン 2 (整数値は 1)を指定していなければなりません。

5.1.2.2 署名  English

このフィールドには、CRL に署名するのに使用されるアルゴリズムのアルゴリズム識別子が入ります。インターネット PKI で最もよく使用されている署名アルゴリズムの OID の一覧がセクション 7.2 に示されています。

このフィールドには、CertificateList シーケンス中の signatureAlgorithm フィールドと同じアルゴリズム識別子が入らなければなりません (セクション 5.1.1.2 を参照)。

5.1.2.3 発行人名  English

発行人名は、CRL に署名してそれを発行したエンティティを識別します。発行人の識別は発行人名フィールドに示されます。代替名称形式を issuerAltName エクステンション中に示すこともできます (セクション 5.2.2 を参照)。発行人名フィールドには X.500 の DN  (DN) が入らなければなりません。発行人名フィールドは、X.501 タイプの名称として定義され、証明書中の発行人名フィールドに対するエンコード規則に適合しなければなりません(セクション 4.1.2.4 を参照)。

5.1.2.4 今回の更新  English

このフィールドは CRL の発行日を示します。ThisUpdate は、 UTCTime または GeneralizedTime としてエンコードできます。

CRL を発行する本方針に適合する CA は、2049年までの日付については thisUpdate を UTCTime としてエンコードしなければなりません。CRL を発行する本方針に適合する CA は、2050年およびそれ以降の日付については thisUpdate を GeneralizedTime としてエンコードしなければなりません。

UTCTime としてエンコードされる場合は、thisUpdate はセクション 4.1.2.5.1 に従って指定され解釈されなければなりません。GeneralizedTime としてエンコードされる場合は、thisUpdate はセクション 4.1.2.5.2 に従って指定され解釈されなければなりません。

5.1.2.5 次回の更新 English

このフィールドは次の CRL が発行される日付を示します。次の CRL は示された日付以前に発行されても構いませんが、示された日付後に発行することはできません。CA は以前のすべての CRL 以後の nextUpdate 日付の付いた CRL を発行すべきです。nextUpdate は UTCTime または GeneralizedTime としてエンコードできます。

本方針は、適合 CA が発行するすべての CRL に nextUpdate を含めることを要求しています。TBSCertList の ASN.1 シンタックスでは、[X.509] で定義されている ASN.1 構造に従ってこのフィールドをオプションとして記述していることに注意してください。nextUpdate が省略されている CRL を処理するクライアントの挙動は本方針では規定されていません。

CRL を発行する本方針に適合する CA は、2049年までの日付については nextUpdate を UTCTime としてエンコードしなければなりません。CRL を発行する本方針に適合する CA は、2050年およびそれ以降の日付については nextUpdate を GeneralizedTime としてエンコードしなければなりません。

UTCTime としてエンコードされる場合は、nextUpdate はセクション 4.1.2.5.1 に従って指定され解釈されなければなりません。GeneralizedTime としてエンコードされる場合は、nextUpdate はセクション 4.1.2.5.2 に従って指定され解釈されなければなりません。

5.1.2.6 取消された証明書 English

取消された証明書の一覧が示されます。取消された証明書はシリアル番号で示されます。CA が取消した証明書は、証明書の固有のシリアル番号で識別されます。また取消し日が示されます。 revocationDate の日付はセクション 5.1.2.4 の説明に従って表されていなければなりません。追加情報を CRL エントリ・エクステンションに加えることができます。CRL エントリ・エクステンションについては 5.3 で説明します。

5.1.2.7 エクステンション English

このフィールドはバージョンが 2 の場合にのみ現れます (セクション 5.1.2.1 を参照)。このフィールドは (現れる場合)、一つあるいはそれ以上の CRL エクステンションからなるシーケンスです。CRL エクステンションについてはセクション 5.2 で説明します。

5.2 CRL エクステンション English

X.509 v2 CRL について ANSI X9 と ISO/IEC/ITU [X.509] [X9.55] によって定義されているこのエクステンションは、追加の属性を CRL に関連付けるための方法を提供します。X.509 v2 CRL フォーマットを使用すると、コミュニティはコミュニティ独自の情報を伝達するプライベート・エクステンションを定義できます。CRL 中の各エクステンションは、クリティカルと指定することもノンクリティカルと指定することもできます。処理方法が分からないクリティカル・エクステンションに遭遇した場合は、CRL 確認が失敗しなければなりません。しかし認識できないノンクリティカル・エクステンションは無視することができます。下記のサブセクションではインターネット CRL 内で使用されるエクステンションを説明します。コミュニティは、本仕様書で定義されていないエクステンションを CRL 中に含めることができますが、一般的な目的で使用される可能性のあるクリティカル・エクステンションを CRL 中に含めるときは十分注意が必要です。

CRL を発行する適合 CA は、発行するすべての CRL 中に、機関鍵識別子エクステンション (セクション 5.2.1 を参照) と CRL 番号エクステンション (セクション 5.2.3 を参照) を含める必要があります。

5.2.1 機関鍵識別子  English

機関鍵識別子エクステンションは、CRL の署名に使用された秘密鍵に対応する公開鍵を識別する手段を提供します。識別は、鍵識別子 (CRL 署名人の証明書中のサブジェクト鍵識別子) に基づいて行うことも、発行人名とシリアル番号に基づいて行うこともできます。このエクステンションは、複数の鍵ペアが同時に存在するかあるいは切換えが行われたかして、発行人が複数の署名鍵を有している場合に特に便利です。

適合 CA はこの鍵識別方法を使用しなければならず、発行するすべての CRL 中にこのエクステンションを含めなければなりません。

この CRL エクステンションのシンタックスはセクション 4.2.1.1 で定義されています。

5.2.2 発行人代替名称  English

発行人代替名称エクステンションを使用すると、追加のアイデンティティを CRL の発行人に関連付けることができます。定義されているオプションとしては、rfc822 名 (電子メール・アドレス)、DNS 名、IP アドレス、および URI があります。名称の複数のインスタンスと複数の名称形式が含まれていても構いません。ただしこの場合は発行人代替名称エクステンションが使用されていなければなりません。

issuerAltName エクステンションはクリティカルと指定すべきではありません。

この CRL エクステンション用の OID とシンタックスはセクション 4.2.1.8 で定義されています。

5.2.3 CRL 番号  English

CRL 番号はノンクリティカルな CRL エクステンションで、CA が発行する各 CRL について一定の割合で増加するシーケンス番号を提供します。このエクステンションにより、ユーザーは特定の CRL がいつ別の CRL に取って代わるかが容易に分かります。本方針に適合する CA はこのエクステンションをすべての CRL に含めなければなりません。

id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

cRLNumber ::= INTEGER (0..MAX)

5.2.4 デルタ CRL インジケータ  English

デルタ CRL インジケータは、デルタ CRL を識別するクリティカルな CRL エクステンションです。デルタ CRL は、CRL 構造以外のフォーマットで取消し情報を保存するアプリケーションの処理時間を大幅に短縮することができます。このインジケータを使用すると、ローカル・データベースの変更されていない情報は無視し、変更されている情報だけをローカル・データベースに反映させることができます。

デルタ CRL が発行されると、CA は完全な CRL も発行しなければなりません。

BaseCRLNumber の値は、この デルタ CRL を生成するときに開始点として使用した基本 CRLのCRL 番号を示しています。デルタ CRL には、基本 CRL と、デルタ CRL と一緒に発行された現行 CRL との相違点が入ります。デルタ CRL を提供するかどうかは CA が決定します。デルタ CRL は、対応する完全な CRL がない状態で発行されてはなりません。CRLNumber の値は、デルタ CRL とそれに対応する完全な CRL とで同一でなければなりません。

ローカル的に維持される CRL をデルタ CRL から構築する CRL ユーザーは、受信されたデルタ CRL のCRLNumber が、最後に処理されたデルタ CRL のCRLnumber より 2 あるいはそれ以上大きい場合、構築された CRL は不完全で使用できないと判断しなければなりません。

id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

deltaCRLIndicator ::= BaseCRLNumber

BaseCRLNumber ::= CRLNumber

5.2.5 発行側の配布ポイント English

発行側の配布ポイントはクリティカルな CRL エクステンションで、特定の CRL について CRL 配布ポイントを示し、CRL が、エンド・エンティティ証明書のみ、CA 証明書のみ、あるいは限られた理由コードのみについて取消しをカバーしているかどうかを示します。本エクステンションはクリティカルですが、適合実装は必ずしも本エクステンションをサポートする必要はありません。

CRL は CA の秘密鍵を使用して署名されます。CRL 配布ポイントは自らの鍵ペアを持っていません。CRL が X.500 ディレクトリに保存される場合は、CRL は CRL 配布ポイントに対応するディレクトリ・エントリ (CA のディレクトリ・エントリとは異なっていてもよい) に保存されます。

配布ポイントに関連する理由コードは onlySomeReasons 中に規定されなければなりません。onlySomeReasons が現れない場合は、配布ポイントにはすべての理由コードの取消しが入らなければなりません。CA は CRL 配布ポイントを使用して、改ざん (compromise) と通常の取消し (routine revocation) に基づいて CRL を分割することができます。この場合は、一つの配布ポイント中に、理由コード keyCompromise (1) と cACompromise (2) の取消しが現れ、別の配布ポイント中に他の理由コードの取消しが現れます。

issuingDistributionPoint エクステンションに URL が入っている場合は、次に示すセマンティックスが想定されなければなりません: オブジェクトはこの CA が発行した最新の CRL を示すポインターである。URI スキームの ftp、http、mailto [RFC1738] および ldap [RFC1778] がこの目的で定義されます。URI は相対経路名ではなくて絶対経路名でなければならず、ホストを指定していなければなりません。

id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

issuingDistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE }

5.3 CRL エントリ・エクステンション English

X.509 v2 CRL について ANSI X9 と ISO/IEC/ITU [X.509] [X9.55] によって定義されているこのエクステンションは、追加の属性を CRL エントリに関連付けるための方法を提供します。X.509 v2 CRL フォーマットを使用すると、コミュニティはコミュニティ独自の情報を伝達するプライベートな CRL エントリ・エクステンションを定義できます。CRL エントリ中の各エクステンションは、クリティカルと指定することもノンクリティカルと指定することもできます。処理方法が分からないクリティカルな CRL エントリ・エクステンションに遭遇した場合は、CRL 確認が失敗しなければなりません。しかし認識できないノンクリティカルな CRL エントリ・エクステンションは無視することができます。下記のサブセクションではインターネット CRL エントリと標準の情報位置内で使用することが推奨されるエクステンションを説明します。コミュニティは、追加の CRLエントリ・エクステンションを使用することもできますが、一般的な目的で使用される可能性のあるクリティカル・エクステンションを CRL 中に含めるときは十分注意が必要です。

本仕様書で使用されるすべての CRL エントリ・エクステンションはノンクリティカルです。適合する CA とアプリケーションがこれらのエクステンションをサポートするかどうかは任意です。しかし、CRL を発行する適合 CA は、理由コード (セクション 5.3.1 を参照) と 無効日 (セクション 5.3.3 を参照) を含めるべきです (この情報が入手可能な場合)。

5.3.1 理由コード  English

reasonCode は証明書取消しの理由を示すノンクリティカルな CRL エントリ・エクステンションです。CA は意味のある理由コードを CRL エントリに入れるようにしてください。しかし、理由コード CRL エントリ・エクステンションは、未指定 (0) の reasonCode 値 を使用するくらいなら省略されるべきです。

id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }

-- reasonCode ::= { CRLReason }

CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
removeFromCRL (8) }

5.3.2 ホールド・インストラクション・コード English

ホールド・インストラクション・コードは、登録済みインストラクション識別子を提供するノンクリティカルな CRL エントリ・エクステンションです。登録済みインストラクション識別子とは、保留になっている証明書に遭遇したときに取るべきアクションを示す識別子です。

id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }

holdInstructionCode ::= OBJECT IDENTIFIER

下記のインストラクション・コードが定義されています。このエクステンションを処理する適合アプリケーションは、下記のインストラクション・コードを認識できなければなりません。

holdInstruction OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) 2 }

id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1}

id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2}

id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

id-holdinstruction-callissuer に遭遇した適合アプリケーションは、証明書の発行人をコールするか、証明書を拒絶しなければなりません。id-holdinstruction-reject に遭遇した適合アプリケーションは、証明書を拒絶しなければなりません。ホールド・インストラクション id-holdinstruction-none は意味的には holdInstructionCode が存在しないのと同じですが、インターネット PKI には使用しないことが強く推奨されます。

5.3.3 無効日  English

無効日は、秘密鍵の秘密が漏れるなどして証明書が無効になった日付、あるいは無効になった可能性のある日付を提供する、ノンクリティカル CRL エントリ・エクステンションです。CA が取消し処理を行う日付は 取消し日としてCRL エントリに入りますが、無効日はこの取消し日より前に設定できます。CA が最初に取消しを CRL に入れたとき、以前の CRL の発行日より無効日の方が早くなっても構いませんが、取消し日は以前の CRL の発行日より早くなってはいけません。この情報が入手可能な場合はいつでも、CA は この情報を CRL ユーザーにも通知することが強く推奨されます。

本フィールド中に含まれている GeneralizedTime 値は、グリニッジ標準時 (Zulu) で表されていなければならず、セクション 4.1.2.5.2 の定義に従って指定され解釈されなければなりません。

id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }

invalidityDate ::= GeneralizedTime

5.3.4 証明書発行人  English

本 CRL エントリ・エクステンションは、間接 CRL (発行側の配布ポイント・エクステンションに indirectCRL インジケータが設定されている CRL) 中のエントリに関連する証明書発行人を識別します。このエクステンションが間接 CRL 中の第 1 エントリ上に存在しない場合は、証明書発行人はデフォルトとして CRL 発行人となります。間接 CRL 中のその後のエントリ上では、このエクステンションが存在しない場合は、そのエントリについての証明書発行人はその前のエントリについての証明書発行人と同じです。このフィールドは次のように定義されています:

id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }

certificateIssuer ::= GeneralNames

CRL を発行する適合 CA によって使用される場合は、このエクステンションは常にクリティカルです。実装がこのエクステンションを無視した場合は、実装は CRL エントリを証明書に正しく関連付けることができません。本仕様書は、実装がこのエクステンションを認識できることを推奨しています。

6 証明書パスの確認 English

インターネット PKI 用の証明書パス確認手順は [X.509] のセクション 12.4.3 に基づいています。証明書パス処理はサブジェクトの DN および/またはサブジェクト代替名称とサブジェクト公開鍵との間のバインドを確認します。このバインドは、証明書パスを構成する証明書の中で指定された制約によって制限されます。基本制約エクステンションおよびポリシー制約エクステンションを使用することにより、証明書パス処理ロジックは決定プロセスを自動化することができます。

本セクションは証明書パスを確認するためのアルゴリズムについて説明しています。本仕様書の適合実装はこのアルゴリズムを適用するうえでは必要ありませんが、この手順の結果として生じる外部挙動と機能的に同等でなければなりません。正しい結果が得られる限り、特定の実装はどのようなアルゴリズムを使用しても構いません。

セクション 6.1 では基本的なパス確認について説明しています。本書は、すべての有効なパスが単一の「最も信用のおける CA」によって発行された証明書で始まることを想定しています。このアルゴリズムは、CA の公開鍵、CA 名、公開鍵の有効期限およびその鍵を使用して確認されるパスの集まりに対する制約を必要とします。

「最も信用のおける CA」はポリシーによります。つまり、「最も信用のおける CA」は、階層 PKI のルート CA であることもあれば、確認者自身の証明書を発行した CA であることもあれば、ネットワーク PKI 上の他の CA であることもあります。パス確認手順は「最も信用のおける CA」としてどの CA を選択したかには関係なく同じです。

セクション 6.2 では基本パス確認アルゴリズムのエクステンションについて説明しています。パスをいくつかの信用のおける CA の一つで始めてもよい場合と、PEM アーキテクチャとの適合性が必要となる場合との 2 つの場合について説明しています。

6.1 基本パスの確認 English

本書では、信用のおける公開鍵 (および関連情報) が「自己署名された」証明書中に含まれていると想定しています。これによりパス処理手順の説明が簡単になります。自己署名された証明書上の署名はセキュリティを高めることにはならないことに注意してください。入手する信用のおける公開鍵 (および関連情報) は他のフォーマットになっていることもありますが、その情報を入手し保護するのに使用される他の手順が信用できればその情報も信用できます。

パス確認の目的は、「最も信用のおける CA」の公開鍵に基づいて、「エンド・エンティティ」証明書で示されている、サブジェクトの DN またはサブジェクトの代替名称とサブジェクトの公開鍵との間のバインドを確認することです。そのためにはそのバインドをサポートする証明書からなるシーケンスを入手する必要があります。このシーケンスを入手するのに実行される手順は本セクションの適用範囲外です。

下記の説明でも、本方針で推奨されているように、証明書がサブジェクトまたは固有の識別子フィールドあるいはプライベートなクリティカル・エクステンションを使用していないと想定しています。しかし、これらのコンポーネントが証明書に現れた場合は処理されなければなりません。また、ポリシー修飾子も説明を単純にするために省略されています。

証明書パスは n 個の証明書からなるシーケンスです。ここで、

* {1,(n-1)} 中のすべての x について、証明書 x のサブジェクトは証明書 x+1 の発行人です。
* 証明書 x=1 は自己署名された証明書です。
* 証明書 x=n はエンド・エンティティ証明書です。

本セクションでは以下の入力がパス処理ロジックに対して提供されると想定しています。

(a) 長さが n の証明書パス;

(b) 一つまたはそれ以上の証明書ポリシーを示す (その内のいずれか一つが証明書パス処理に適する)、初期ポリシー識別子の集まりか (各識別子はポリシー・エレメント識別子のシーケンスから構成される)、あるいは特殊値である "any-policy";

(c) 現在の日付/時刻 (証明書パス処理モジュールが内部的に得ることができない場合); および

(d) パスの有効性が判定されるべき時刻 T (これは現在の日付/時刻でも過去のある時点でも構いません) 。

これらの入力を使用して、この手順は次の 5 つの状態変数を初期化します。

(a) 正しいポリシーの集まり: ポリシー・マッピングによって同等とされた複数のポリシーと、公開鍵ユーザーによって認識された一つあるいはそれ以上のポリシーとからなる証明書ポリシー識別子の集まり。正しいポリシーの集まりの初期値は特殊値である "any-policy"です。

(b) 制約されたサブツリー: 証明書パス中の以降の証明書中のすべてのサブジェクト名が入るサブツリーの集まりを定義するルート名の集まり。初期値は "unbounded" です。

(c) 除外されたサブツリー: 証明書パス中の以降の証明書中のサブジェクト名が全く入っていないサブツリーの集まりを定義するルート名の集まり。初期値は "empty" です。

(d) 明示的なポリシー: 明示的なポリシー識別子が必要であるかを示す整数。この整数は、この要求が課せられたパス中の最初の証明書を示します。この変数は、いったんセットされると、小さくすることはできますが大きくすることはできません。 (つまり、パス中のある証明書が明示的なポリシー識別子を必要とする場合、以降の証明書はこの要求を削除できません)。初期値は n+1 です。

(e) ポリシー・マッピング: ポリシー・マッピングが許可されるかどうかを示す整数。この整数はポリシー・マッピングが適用される最後の証明書を示します。この変数は、いったんセットされると小さくすることができますが大きくすることはできません。 (つまり、パス中のある証明書がポリシー・マッピングは許可されないと指定すると、以降の証明書はその指定を変更することはできません。初期値は n+1 です。

i=1 から i=n までの各証明書についてパス処理ソフトウェアが実行するアクションについて以下で説明します。自己署名された証明書は証明書 i=1 で、エンド・エンティティ証明書は i=n です。処理は逐次的に実行されるので、証明書 i の処理は、証明書 (i+1) を処理するための状態変数に影響を与えます。アクション (h) 〜 (m) はエンド・エンティティ証明書 (証明書 n) には適用されないことに注意してください。

実行されるパス処理アクションは次のとおりです。

(a) 少なくとも下記の基本的な証明書情報を確認する:

(1) 証明書が、証明書 i-1 からのサブジェクト公開鍵を使用して署名されていること (i=1 の場合、このステップは省略できます。省略しない場合は、同じ証明書のサブジェクト公開鍵を使用してください)。

(2) 証明書の有効期限に時刻 T が含まれていること。

(3) 証明書は時刻 T の時点で失効しておらず、時刻 T 以前に開始した保留状態が現在まで続いていないこと。 (このことは、適切な CRL またはステータス情報を入手するか、帯域外 (out-of-band) 機構によって確認できます) 。

(4) サブジェクト名と発行人名が正しくチェーンしていること。 (つまり、この証明書の発行人が以前の証明書のサブジェクトであったこと) 。

(b) サブジェクト名および subjectAltName エクステンション (クリティカルまたはノンクリティカル) が制約されたサブツリー状態変数と矛盾していないことを確認する。

(c) サブジェクト名および subjectAltName エクステンション (クリティカルまたはノンクリティカル) が除外されたサブツリー状態変数と矛盾していないことを確認する。

(d) ポリシー情報が初期ポリシーの集まりと矛盾していないことを確認する:

(1) 明示的なポリシー状態変数が i かそれ以下である場合、証明書のポリシー識別子は初期のポリシーの集まり中に含まれていなければなりません。

(2) ポリシー・マッピング変数が i かそれ以下である場合、ポリシー識別子はマッピングされていなくても構いません。

(e) ポリシー情報が正しいポリシーの集まりと矛盾していないことを確認する。

(1) 証明書ポリシー・エクステンションがクリティカルに指定されている場合、ポリシー・エクステンションと正しいポリシーの集まりとの接点 (intersection) は空文字以外 (non-null) でなければなりません。

(2) 正しいポリシーの集まりには、その接点が新しい値として割当てられます。

(g) 正しいポリシーの集まりと初期ポリシーの集まりとの接点が空文字以外であることを確認する。

(h) 証明書に存在する他のすべてのクリティカル・エクステンションを認識し処理する。

(i) 証明書が CA 証明書であることを確認する (basicConstraints エクステンションで指定されているように、あるいは帯域外であると確認されているように)。

(j) 証明書に permittedSubtrees が存在する場合、制約されたサブツリー状態変数を、以前の値とエクステンション・フィールドに示された値との接点にセットする。

(k) 証明書に excludedSubtrees が存在する場合、除外されたサブツリー状態変数を以前の値とエクステンション・フィールドに示された値との接点にセットする。

(l) ポリシー制約エクステンションが証明書に含まれている場合、下記のように、明示的なポリシーおよびポリシー・マッピング状態変数を変更する:

(1) requireExplicitPolicy が存在していてその値が r である場合、明示的なポリシー状態変数は、現在値か、 r と i (シーケンス中の現行の証明書) の合計かの、いずれかより小さい値にセットされます。

(2) inhibitPolicyMapping が存在していてその値 が q である場合、ポリシー・マッピング状態変数は、現在値か、 q と i (シーケンス中の現行の証明書) の合計かの、いずれかより小さい値にセットされます。

(m) 鍵用途エクステンションがクリティカルに指定されている場合、keyCertSign ビットをセットする。

上記のチェックが一つでも失敗した場合、手順は、失敗表示と失敗の理由を返してから終了します。エンド・エンティティ証明書で上記のチェックが一つも失敗しなかった場合、証明書の集まりの中で遭遇したすべてのポリシー修飾子の値の集まりと共に成功表示を返してから手順は終了します。

6.2 パス確認の拡張 English

6.1 で説明されているパス確認アルゴリズムはいくつかの簡略化のための前提事項に基づいています (たとえば、単一の信用のおける CA からすべての有効パスが開始するなど)。この前提事項が当てはまらない場合には、このアルゴリズムを拡張することができます。

この手順は、自己署名された証明書の集まりを確認モジュールに提供することによって、複数の信用のおける CA について拡張することができます。この場合、正しいパスは自己署名された証明書のうちのいずれからでも開始できます。任意の鍵に対する信用パスを、自己署名された証明書のエクステンションで制限することもできます。自己署名された証明書を使用することによって、パス確認モジュールは自動的にローカル・セキュリティ・ポリシーと要求事項を取込むことができるようになります。

結果的に PEM 規則 [RFC 1422] と同一のデフォルト挙動となるように、上記の証明書パス処理手順の拡張バージョンを指定することも可能です。この拡張バージョンでは、手順に対する追加入力は、一つあるいはそれ以上のポリシー認証機関 (PCA) 名の一覧と、証明書パス中の PCA の位置を示すポインターとから構成されます。指定された PCA 位置で、 CA 名はこの一覧と比較されます。指定された PCA 名が見つかった場合は、証明書パスの残りの部分について SubordinateToCA の制約が暗に想定され、処理が続行されます。指定された PCA 名が見つからなかった場合は、識別されたポリシーに基づいて証明書パスが確認できなければ、その証明書パスは無効と見なされます。

7 アルゴリズムのサポート English

本セクションでは、本方針に基づいて使用できる暗号化アルゴリズムを説明します。本セクションは、証明書と CRL に署名するのに使用できる一方向ハッシュ関数とデジタル署名について説明し、証明書に入れる公開鍵の OID を示します。

適合 CA および適合アプリケーションは本セクションで説明されているアルゴリズムまたはアルゴリズム識別子を必ずしもサポートする必要はありません。しかし、適合 CA および適合アプリケーションは、ここで識別されるアルゴリズムを使用する場合は、規定されているようにサポートしなければなりません。

7.1 一方向ハッシュ関数 English

本セクションはインターネット PKI で使用する一方向ハッシュ関数を示しています。一方向ハッシュ関数はメッセージ・ダイジェスト・アルゴリズムとも呼ばれます。 SHA-1 はインターネット PKI 用に推奨される一方向ハッシュ関数です。しかし、PEM は MD2 を証明書用に使用し [RFC 1422] [RFC 1423]、 MD5 は他の従来のアプリケーションに使用されているので、MD2 と MD5 の両方が本方針に含まれています。

7.1.1 MD2 一方向ハッシュ関数  English

MD2 は RSA Data Security社の Ron Rivest 氏によって開発されました。 RSA Data Security社は MD2 アルゴリズムをパブリック・ドメインには置かず、非商業的なインターネット・プライバシー強化メール用に MD2 を使用するライセンスを許可しています。このため、 MD2 は今後も PEM 証明書に使用できますが、 SHA-1 を使用することが推奨されます。 MD2 は 128 ビットの「ハッシュ」入力を生成します。 MD2 は RFC 1319 [RFC 1319] で詳しく説明されています。

1995 年 5 月に行われた Cryptography '95 会議の専門部会 (Selected Areas) で、Rogier と Chauvaud は、ほぼ衝突を発見できる MD2 に対する攻撃を発表しました [RC95] 。衝突は、同一のメッセージ・ダイジェストを生成する 2 つの異なるメッセージを攻撃者が発見できたときに起こります。 MD2 のチェックサムだけでこの攻撃が防がれています。このため、新規のアプリケーションに MD2 を使用することは推奨されません。しかし、 MD2 には衝突を発見できる能力があり、攻撃者は以前に計算されたハッシュ値を有する新規のメッセージを発見することはできないので、MD2 を使用して既存の署名を確認することはできます。

7.1.2 MD5 一方向ハッシュ関数 English

MD5 は RSA Data Security社の Ron Rivest 氏によって開発されました。 RSA Data Security社は MD5 アルゴリズムをパブリック・ドメインに置いています。MD5は 128 ビットの「ハッシュ」入力を生成します。 MD5 は RFC 1321 [RFC 1321] で詳しく説明されています。

Den Boer と Bosselaers [DB94] は MD5 用の擬似衝突を発見しました。しかし、これ以外に知られた暗号解読結果はありません。新しいアプリケーションに MD5 を使用することは推奨されていませんが、既存の署名を確認するのに MD5 を使用することはできます。

7.1.3 SHA-1 一方向ハッシュ関数 English

SHA-1 は米国政府によって開発されました。SHA-1 は 160 ビットの「ハッシュ」入力を生成します。 SHA-1 は FIPS 180-1 [FIPS 180-1] で詳しく説明されています。

SHA-1 は、 RSA と DSA の両方の署名アルゴリズム (セクション 7.2 を参照) で使用できる、推奨される一方向ハッシュ関数です。

7.2 署名アルゴリズム English

本規格で説明されている証明書および CRL は、どの公開鍵署名アルゴリズムでも署名できます。証明書あるいは CRL は、Certificate あるいは CertificateList の signatureAlgorithm フィールド中に現れるアルゴリズム識別子によってアルゴリズムを示します。このアルゴリズム識別子は OID で、オプションとして関連パラメータを有しています。本セクションは、Certificate あるいは CertificateList の signatureAlgorithm フィールド中で使用されなければならないアルゴリズム識別子およびパラメータを示しています。

RSA および DSA はインターネットで使用される最もよく知られた署名アルゴリズムです。署名アルゴリズムは、セクション 7.1 で説明されている一方向ハッシュ関数と常に組合わせて使用されます。

証明書または CRL に署名するのに使用される署名アルゴリズムおよび一方向ハッシュ関数は、アルゴリズム識別子で示されます。アルゴリズム識別子は OID で、関連パラメータを含むことができます。本セクションは RSA と DSA の両方の OID を示しています。パラメータ・コンポーネントの内容はアルゴリズムによって異なるので、各アルゴリズムごとに詳しく説明します。

署名対象のデータ (たとえば、一方向ハッシュ関数出力値) は署名アルゴリズムが使用できるようにフォーマットされます。次に、秘密鍵 (たとえば、 RSA 暗号化) を使用して署名値を生成します。この署名値は次にビット・ストリングとして ASN.1 エンコードされ、署名フィールドのCertificate あるいは CertificateList に入れられます。

7.2.1 RSA 署名アルゴリズム English

RSA 署名アルゴリズムに関する特許ステートメントが本方針の最後に示されています。

RSA アルゴリズムはその発明者である Rivest、Shamir、Adleman に因んで命名されています。本方針には RSA 非対称暗号化アルゴリズムに基づいた 3 つの署名アルゴリズムが示されています。この 3 つの署名アルゴリズムは、RSA を MD2 一方向ハッシュ関数、MD5 一方向ハッシュ関数、SHA-1 一方向ハッシュ関数のいずれかと組合わせています。

MD2 と RSA 暗号化アルゴリズムを使用した署名アルゴリズムは PKCS #1 [RFC 2313] で定義されています。RFC 2313 で定義されているように、この署名アルゴリズムを示すのに使用される ASN.1 OID は次のとおりです。

md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }

MD5 と RSA 暗号化アルゴリズムを使用した署名アルゴリズムは PKCS #1 [RFC 2313] で定義されています。RFC 2313 で定義されているように、この署名アルゴリズムを識別するのに使用される ASN.1 OID は次のとおりです。

md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

SHA-1 と RSA 暗号化アルゴリズムを使用した署名アルゴリズムは PKCS #1 [RFC 2313] で説明されているパディングおよびエンコーディング法を使用して実施されます。メッセージ・ダイジェストは SHA-1 ハッシュ・アルゴリズムを使用して計算されます。この署名アルゴリズムを示すのに使用される ASN.1 オブジェクト識別子は次のとおりです。

sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

ASN.1 タイプの AlgorithmIdentifier にこれら3 つの OID のいずれかが現れるときは、そのタイプのパラメータ・コンポーネントは ASN.1 タイプの 空文字 (NULL) でなければなりません。

RSA 署名生成プロセスおよびその結果のエンコーディングが RFC 2313 で詳しく説明されています。

7.2.2 DSA 署名アルゴリズム  English

DSA に関する特許ステートメントが本方針の最後に示されています。

デジタル署名アルゴリズム (DSA) はデジタル署名規格 (DSS) とも呼ばれます。DSA は米国政府によって開発されたもので、 SHA-1 一方向ハッシュ関数と組み合わせて使用します。 DSA は FIPS 186 [FIPS 186] で詳しく説明されています。この署名アルゴリズムを示すのに使用される ASN.1 OID は次のとおりです。

id-dsa-with-sha1 ID ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }

id-dsa-with-sha1 アルゴリズム識別子が AlgorithmIdentifier 中にアルゴリズム・フィールドとして現れるときは、エンコーディングはパラメータ・フィールドを省略しなければなりません。つまり、 AlgorithmIdentifier は一つのコンポーネント (オブジェクト識別子 id-dsa-with-sha1) からなるシーケンスでなければなりません。

発行人の証明書の subjectPublicKeyInfo フィールド中の DSA パラメータは署名の確認に適用しなければなりません。

署名時に DSA アルゴリズムは 2 つの値を生成します。この値は通例 r と s として表します。これら 2 つの値を一つの署名として簡単に伝達するためには、この値は以下の ASN.1 構造を使用して ASN.1 エンコードされなければなりません。

Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }

7.3 サブジェクト公開鍵アルゴリズム English

本方針で説明されている証明書はどの公開鍵アルゴリズムについても公開鍵を伝達できます。証明書はアルゴリズム識別子でそのアルゴリズムを示します。このアルゴリズム識別子は OID で、オプションとして関連パラメータを含むことができます。

本セクションは、RSA、DSA、Diffie-Hellman の各アルゴリズムについて、推奨される OID とパラメータを示しています。適合 CA は、これらのアルゴリズムについて公開鍵の入った証明書を発行するときに、ここで示された OID を使用しなければなりません。これらのアルゴリズムのいずれかをサポートしている適合アプリケーションは、最低限でも本セクションで示されている OID を認識できなければなりません。

7.3.1 RSA 鍵 English

OID rsaEncryption は RSA 公開鍵を示します。

pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}

rsaEncryption OID は AlgorithmIdentifier タイプの値を持つアルゴリズム・フィールドで使用します。このアルゴリズム識別子について、パラメータ・フィールドには ASN.1 タイプの 空文字 (NULL) が入らなければなりません。

RSA 公開鍵は ASN.1 タイプの RSAPublicKey を使用してエンコードされなければなりません。

RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e -- }

このとき係数は n で、 publicExponent はパブリック・エクスポーネント e です。DER エンコードされた RSAPublicKey は ビット・ストリング subjectPublicKey の値です。

この OID は、公開鍵証明書において RSA 署名鍵と RSA 暗号鍵の両方に使用されます。この鍵のアプリケーションは鍵用途フィールド (セクション 4.2.1.3 を参照) に示すことができます。署名と暗号化の両方の目的で単一の鍵を使用することは推奨されていませんが、禁止されているわけではありません。

keyUsage エクステンションが RSA 公開鍵を伝達するエンド・エンティティ証明書中に存在する場合、次の値をどのように組合わせても構いません: digitalSignature、nonRepudiation、keyEncipherment、および dataEncipherment。keyUsage エクステンションが RSA 公開鍵を伝達する CA 証明書中に存在する場合、次の値をどのように組合わせても構いません: digitalSignature、nonRepudiation、keyEncipherment、dataEncipherment、keyCertSign、および cRLSign。しかし、本仕様書では keyCertSign または cRLSign が存在する場合、 keyEncipherment と dataEncipherment の両方が存在しないことを推奨しています。

7.3.2 Diffie-Hellman 鍵交換鍵 English

本方針がサポートする Diffie-Hellman の OID は ANSI X9.42 [X9.42] によって定義されています。

dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

dhpublicnumber OID は AlgorithmIdentifier タイプの値を持つアルゴリズム・フィールドで使用します。アルゴリズムに固有のシンタックスである ANY DEFINED BY アルゴリズムを有するこのタイプのパラメータ・フィールドには、このアルゴリズム用の ASN.1 タイプの DomainParameters が入ります。

DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor
validationParms ValidationParms OPTIONAL }
 
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }

DomainParameters タイプの各フィールドには次の意味があります。

p は Galois フィールドを定義する素数 p を示します。

g は次数 gの乗法サブグループのジェネレータ (generator) を指定します。

q は p-1 の素数係数を指定します。

j は、グループ・パラメータを確認するために、等式 p=jq+1 を満足する値を指定します (オプション)。

シード (seed) はシステム・パラメータ生成プロセスのシードとして使用されるビット・ストリング・パラメータを指定します (オプション)。

pgenCounter はシステム・パラメータ素数生成プロセスの一部として、整数値出力を指定します (オプション)。

パラメータ生成コンポーネント (pgencounter またはシード) のどちらか一方が存在する場合は、同時に他方も存在しなければなりません。

Diffie-Hellman 公開鍵は 整数として ASN.1 エンコードされなければなりません。このエンコーディングは subjectPublicKeyInfo データ・エレメントの subjectPublicKey コンポーネント (ビット・ストリング) の内容 (値) として使用しなければなりません。

DHPublicKey ::= INTEGER -- public key, y = g^x mod p

KeyUsage エクステンションが DH 公開鍵を伝達する証明書中に存在する場合、次の値が使用できます: KeyAgreement、encipherOnly、および decipherOnly。encipherOnly と decipherOnly のうち、一つしか keyUsage エクステンション中で有効になりません。

7.3.3 DSA 署名鍵  English

デジタル署名アルゴリズム (DSA) はデジタル署名規格 (DSS) とも呼ばれます。本方針がサポートする DSA OID は次のとおりです。

id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

id-dsa アルゴリズム・シンタックスにはオプションのパラメータが入ります。このパラメータは通例 p 、 q および g として表されます。パラメータが省略される場合は、パラメータ・コンポーネント全体が省略されなければなりません。つまり、 AlgorithmIdentifier は一つのコンポーネント (オブジェクト識別子 id-dsa) からなるシーケンスでなければなりません。

DSA アルゴリズム・パラメータが subjectPublicKeyInfo AlgorithmIdentifier に存在する場合、そのパラメータは次の ASN.1 構造を使用して含めなければなりません。

Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }

DSA アルゴリズム・パラメータが subjectPublicKeyInfo AlgorithmIdentifier に存在しない場合で、かつ CA が DSA を使用してサブジェクト証明書に署名した場合、その証明書の発行人の DSA パラメータはそのサブジェクトの DSA 鍵に適用されます。DSA アルゴリズム・パラメータが subjectPublicKeyInfo AlgorithmIdentifier に存在しない場合で、かつ CA が DSA 以外の署名アルゴリズムを使用してサブジェクト証明書に署名した場合、そのサブジェクトの DSA パラメータは別の手段で配布されます。subjectPublicKeyInfo AlgorithmIdentifier フィールドがパラメータ・コンポーネントを省略する場合で、かつ CA が DSA 以外の署名アルゴリズムを使用してサブジェクトに署名した場合、クライアントはその証明書を拒絶しなければなりません。

署名時に、 DSA アルゴリズムは 2 つの値を生成します。この値は一般に r および s と表されます。この 2 つの値を一つの署名として簡単に伝達するために、この値は次の ASN.1 構造を使用して ASN.1 エンコードされます。

Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }

エンコードされた署名は、Certificate または CertificateList 中のビット・ストリング 署名の値として伝達されます。

DSA 公開鍵は整数として ASN.1 DER エンコードされなければなりません。このエンコーディングは STRINGSubjectPublicKeyInfo データ・エレメントの subjectPublicKey コンポーネント (ビット・ストリング) の内容 (値) として使用されなければなりません。

DSAPublicKey ::= INTEGER -- public key, Y

keyUsage エクステンションが DSA 公開鍵を伝達するエンド・エンティティ証明書中に存在する場合、次の値をどのように組み合わせても構いません: digitalSignature および nonRepudiation。

keyUsage エクステンションが DSA 公開鍵を伝達する CA 証明書中に存在する場合、次の値をどのように組み合わせても構いません: digitalSignature、nonRepudiation、keyCertSign、および cRLSign。

 

8 参考文献

[FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 1995年 4月17日. [Supersedes FIPS PUB 180 dated 1993年 5月11日.]
 
[FIPS 186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 1994年 5月18日.
 
[RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2 is not collision free," Presented at Selected Areas in Cryptography '95, 1995年 5月.
 
[RFC 791] Postel, J., "Internet Protocol",
STD 5, RFC 791, 1981年 9月.
 
[RFC 822] Crocker, D., "Standard for the format of ARPA Internet text messages",
STD 11, RFC 822, 1982年 8月.
 
[RFC 1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, 1987年11月.
 
[RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm,"
RFC 1319, 1992年 4月.
 
[RFC 1321] Rivest, R., 
「MD5 メッセージダイジェストアルゴリズム(The MD5 Message-Digest Algorithm)」,
 RFC 1321, 1992年 4月.
 
[RFC 1422] Kent, S.,
"Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management,"
RFC 1422, 1993年 2月.
 
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers,"
RFC 1423, 1993年 2月.

[RFC 1519] Fuller, V., Li, T., Yu, J. and K. Varadhan.
"Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy",
RFC 1519, 1993年 9月.

[RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill.
"Uniform Resource Locators (URL)",
RFC 1738, 1994年12月.

[RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The String Representation of Standard Attribute Syntaxes,"
RFC 1778, 1995年 3月.

[RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification",
RFC 1883, 1995年12月.

[RFC 2119] Bradner, S., 
「RFC において要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」,
 BCP 14, RFC 2119, 1997年 3月.

[RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri.
"Using Domains in LDAP/X.500 Distinguished Names",
RFC 2247, 1998年 1月.

[RFC 2277] Alvestrand, H.,
"IETF Policy on Character Sets and Languages",
RFC 2277, 1998年 1月.

[RFC 2279] Yergeau, F.,
"UTF-8, a transformation format of ISO 10646",
RFC 2279, 1998年 1月.

[RFC 2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, 1998年 3月.

[SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A 1997-02-06.

[X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988年.

[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993年.

[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, 1997年 6月.

[X.520] ITU-T Recommendation X.520: Information Technology - Open Systems Interconnection - The Directory: Selected Attribute Types, 1993年.

[X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial Services Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman (Working Draft), 1997年12月.

[X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial Services Industry: Extensions To Public Key Certificates And Certificate Revocation Lists, 1995年12月 8日.

[X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial Services Industry: Certificate Management (Working Draft), 1996年 6月21日.

 

9 知的財産権 English

IETF は、本文書の仕様書の一部あるいはすべてについて主張されている知的財産権について通知を受けています。詳細については主張されている権利のオンライン・リストを参照してください。

IETF は、本文書に記述されている技術の実装あるいは使用に関連していると主張されるかもしれない知的財産権などの権利の有効性あるいは適用範囲に関して、あるいはそのような権利の下でライセンスが得られる範囲に関して、一切関与するものではありません。IETF はまた、そのような権利を識別するために努力を払ったと表明するものでもありません。規格トラック (standards-track) および規格関連文書についての IETF 手順については BCP-11 を参照してください。公開されている権利の主張のコピーおよび利用可能なライセンスの保証、あるいは本仕様書の実装者あるいはユーザーがそのような知的財産権を使用するための一般ライセンスあるいは許可を得ようとした努力の結果がIETF 事務局から入手できます。

 

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

本仕様書の大部分は、証明書と CRL のフォーマットと内容にあてられています。証明書と CRL はデジタル署名されるので、追加のインテグリティ・サービス (integrity service) は必要ありません。証明書も CRL も秘密にする必要はなく、証明書と CRL に対して無制限、無記名のアクセスを許してもセキュリティには何ら影響しません。

しかし、本仕様書の適用範囲外のセキュリティ要因は、証明書ユーザーに提供される保証に影響を与えます。本セクションは、実装者、管理者、およびユーザーが考慮すべき重要な問題に焦点を当てています。

サブジェクトの公開鍵のアイデンティティのバインド を CA と RA が確認する手順により、証明書の持つ保証の度合いが大きく変わります。証明書を頼りにする側が、証明書についての CA の実施方針の確認を望むのは当然のことです。特に、他の CA に対して証明書を発行する際には重要です。

単一の鍵ペアを署名とそれ以外の目的の両方に使用することは極力避けてください。署名用と鍵管理用に別々の鍵ペアを使用することで、ユーザーはいくつかの利点が得られます。署名用の鍵と鍵管理用の鍵では、紛失または漏洩により起こる派生問題が異なります。署名用と鍵管理用に別々の鍵ペアを使用することで、安定した柔軟性のある応答が保証されます。同様に、アプリケーション環境によっては、鍵ペアごとに異なる有効期限あるいは鍵の長さを割り当てた方がよい場合があります。残念なことに、従来のアプリケーション(たとえば SSL)によっては単一の鍵ペアが署名用と鍵管理用の両方に使用されています。

秘密鍵の保護は、セキュリティを維持するうえで非常に重要です。ユーザーが自分の秘密鍵を守ることができなければ、攻撃者がユーザーの名をかたったりユーザーの情報を解読したりできることになります。また、CA の秘密の署名鍵が改ざんされた場合にはその影響ははかり知れない程大きなものとなります。攻撃者が気づかれずに秘密鍵を手に入れたとしたら、攻撃者は偽の証明書と CRL を発行できることになります。偽の証明書と CRL が出回ると、システム全体の信用が無くなります。秘密鍵が盗難にあったことが判明すれば、そのCA に対して発行されたすべての証明書を失効させなければならず、その CA のユーザーと他の CA のユーザーとの間のサービスが禁止されます。秘密鍵が盗難にあった後では再構築も問題です。このようなことを避けるため、CA は強力な技術的対策(たとえば悪用防止暗号モジュールを使用する)と適切な管理手順 (たとえば責任分割) とを組合わせて実施することが強く推奨されます。

CA の秘密の署名鍵が紛失しても問題が生じます。CA は CRL を発行できなくなったり、通常の鍵ロールオーバーを実行できなくなります。CA は署名用の鍵を安全な方法でバックアップしておくことが推奨されます。鍵のバックアップ手順がセキュアであるかどうかが、鍵の悪用を防止するうえで非常に重要です。

失効情報の可用性および更新度が、証明書に与えられるべき保証の度合いに影響します。証明書の有効期限は自然に切れますが、サブジェクトと公開鍵との間のバインドを無効にするようなイベントが有効期限が切れる前に発生することがあります。失効情報が遅れたりあるいは全く入手できなければ、バインドに関連する保証の度合いが明らかに低下します。同様に、セクション 6 で説明されている、失効チェックを省略するパス確認機構の実装は、失効チェックをサポートするパス確認機能の実装に比べて度合いの低い保証しか提供できません。

パス確認アルゴリズムは、一つあるいはそれ以上の信用のおける CA についての公開鍵 (およびその他の情報) に関する知識の有無で大きく影響されます。CA を信用するかどうかの判断は、証明書に与えられる信用を究極的に決定することになるので、とても重要な判断となります。信用のおける CA の公開鍵をどのようにすれば安全に配布できるか (通常は「自己署名した」証明書として配布する) ということは、本仕様書の適用範囲外の、セキュリティ・クリティカルな帯域外のプロセスです。

また、信用のおける CA で鍵の改ざんあるいは CA の失敗が発生した場合は、ユーザーはパス確認ルーチンに対して提供されている情報を変更する必要があります。信用のおける CA を余りにも多く選択すると、信用のおける CA に関する情報の維持が困難になります。これとは逆に、信用のおける CA を一つしか選択しなかった場合は、グローバルな PKI が現れるまでは、ユーザーは閉ざされたユーザー・コミュニティに限定されることになります。

証明書を処理する実装の品質も、提供される保証の度合いに影響を与えます。セクション 6 で説明されているパス確認アルゴリズムは、信用のおける CA の情報の正しさ、とくに信用のおける CA の公開鍵の正しさに依存しています。攻撃者がある公開鍵に対して秘密鍵を有している場合、攻撃者はその公開鍵を使用することによって、偽の証明書を本物であるとユーザーに信じ込ませることができます。

鍵と証明書のサブジェクトとの間のバインドは、署名を作成するのに使用された暗号化モジュール実装とアルゴリズムより強くなることはありません。鍵の長さが短かったり、ハッシュ・アルゴリズムが弱かったりすると、それだけ証明書の機能が限定されます。CA は、強い暗号技術を使えるように、暗号学の進歩に常に注意を払うようにしてください。また、CA は弱い署名を作成する CA あるいはエンド・エンティティに対して証明書を発行しないようにすべきです。

名称比較規則の適用に一貫性がないと、無効な X.509 証明書パスが受入れられたり、有効な証明書パスが拒絶されたりする可能性があります。 X.500 シリーズの仕様書は、 DN を比較するための規則は、大文字と小文字の区別、文字セット、多文字空スペース・サブストリング、あるいは先頭と末尾の空スペースを無視してストリングを比較するようにと規定しています。本仕様書はこれらの要求事項を緩和しており、少なくともバイナリ比較をサポートするようにと要求しています。

CA は、CA 証明書のサブジェクト・フィールド中の DN を、後者の CA が発行した証明書中の発行人フィールド中の DN と全く同じようにエンコードしなければなりません。CA が異なったエンコーディングを使用した場合には、この仕様書の実装は、この証明書を含むパスについての名称チェーンを認識できなくなる可能性があります。その結果、正しいパスが拒絶されることになります。

また、 DN に対する名称制約は、サブジェクト・フィールドあるいは subjectAltName エクステンション中で使用されているエンコーディングに対してと全く同じように記述されていなければなりません。そうでないと、(1) excludedSubTrees として記述されている名称制約はマッチせず、無効なパスが誤って受入れられることになり、(2) permittedSubtrees として表されている名称制約はマッチせず、有効なパスが誤って拒絶されることになります。無効なパスが受入れられることがないようにするため、 DN に対する名称制約は、できるだけpermittedSubtrees として記述されるべきです。

 


付録 A. ASN.1 に似た構造と OIDs English

本セクションでは、適合 PKI コンポーネントが 「ASN.1 に似た」シンタックス中で使用するデータ・オブジェクトを説明します。このシンタックスは、1988 年と 1993 年の ASN.1 シンタックスを組合わせたものです。つまり、1988 年のASN.1 シンタックスが、1993 年の UNIVERSAL タイプの UniversalString、BMPString および UTF8String と組合わされて強化されています。

ASN.1 シンタックスは、タイプ・ステートメントを ASN.1 モジュールに含めることを許可していません。また、1993 ASN.1 規格は 1988 年のシンタックスを使用して新しい UNIVERSAL タイプをモジュールに使用することを許可していません。このため、本モジュールは ASN.1 規格のどちらのバージョンとも適合しなくなりました。

本付録は、UNIVERSAL タイプに対する定義を 1988 年バージョンの "ANY (任意)" に対する定義と入替えると、そのまま 1988 ASN.1 として使えます。

A.1 明示的にタグ表示されたモジュール、1988 シンタックス

A.2 暗示的にタグ表示されたモジュール、1988 シンタックス

 


付録 B. 1993 ASN.1 構造および OID English

B.1 明示的にタグ表示されたモジュール、1993 シンタックス

B.2 暗示的にタグ表示されたモジュール、1993 シンタックス

 


付録 C. ASN.1 の注意事項 English

コンストラクト "SEQUENCE SIZE (1..MAX) OF" がいくつかの ASN.1 コンストラクト中で使用されています。有効な ASN.1 シーケンスは 0 個かそれ以上のエントリを有しています。SIZE (1..MAX) コンストラクトでは、シーケンス中に少なくとも一つのエントリが入っている必要があります。 MAX はアッパー・バウンドが規定されていないことを示します。実装は実装環境に合ったアッパー・バウンドを自由に選択できます。

コンストラクト "positiveInt ::= INTEGER (0..MAX)" は、ゼロ以上の整数が入っている INTEGER のサブタイプとして positiveInt を定義します。アッパー・バウンドは指定されません。実装は実装環境に合ったアッパー・バウンドを自由に選択できます。

文字ストリング・タイプ PrintableString は非常に基本的なラテン文字セットをサポートします: 小文字の 'a' から 'z' まで、大文字の 'A' から 'Z' まで、数字の '0' から '9' まで、11 個の特殊文字 ' " ( ) + , - . / : ? およびスペース。

文字ストリング・タイプ TeletexString は PrintableString のスーパーセットです。TeletexString は標準的な (ASCIIに似た) ラテン文字セット (ノン・スペーシング・アクセント付きのラテン語と日本語) をサポートします。

文字ストリング・タイプ UniversalString は ISO 10646-1 が許可しているすべての文字をサポートします。ISO 10646 は、ユニバーサルな、複数のオクテットでコーディングされた文字セット (UCS) です。ISO 10646-1 は、アーキテクチャと「基本的な多言語基盤」 (世界の主要な文字標準をすべて含んでいる大規模な標準文字セット) を規定しています。

文字ストリング・タイプ UTF8String は、ASN.1 の 1998 年バージョンに組入れられる予定です。UTF8String はユニバーサル・タイプで、タグ番号 12 が割当てられています。UTF8String の内容は RFC 2044 で定義され、RFC 2279 「UTF-8、ISP 10646 の変換フォーマットの一つ」で更新されました。ISO は 1998 年に正式に UTF8String を DirectoryString 用の選択肢の一つに加える予定です。

予定されているこれらの変更を考慮して、また、RFC 2277 「文字セットと言語に関する IETF の方針」として成文化されている IETF 推奨規格に準拠して、本文書は UTF8String を一つの選択肢として DirectoryString と CPS 修飾子エクステンションに含めています。

 


付録 D. 例 English

本セクションでは、3 つの証明書の例と 1 つの CRL の例を示します。最初の 2 つの証明書と CRL が最低限の証明書パスを構成しています。

セクション D.1 は、 DN が cn=us、o=gov、ou=nist である CA が発行した「自己署名された」証明書の注釈付き 16 進ダンプを示しています。この証明書には、パラメータ付きの DSA 公開鍵が入っており、対応する DSA 秘密鍵によって署名されています。

セクション D.2 は、エンド・エンティティ証明書の注釈付き 16 進ダンプを示しています。このエンド・エンティティにはDSA 公開鍵が入っており、セクション D.1 の「自己署名された」証明書に対応する秘密鍵によって署名されています。

セクション D.3 は、RSA 公開鍵が入っていて RSA と MD5 で署名されているエンド・エンティティ証明書のダンプを示しています。この証明書は最低限の証明書パスの一部ではありません。

セクション D.4 は、CRL の注釈付き 16 進ダンプを示しています。この CRL は、 DN が cn=us、o=gov、ou=nist の CA によって発行されています。証明書失効リストには、D.2 で示されているエンド・エンティティ証明書が含まれています。

D.1 証明書

このセクションは、699 バイトのバージョン 3 の証明書の注釈付き 16 進ダンプを示しています。この証明書には次の情報が示されています:
(a) シリアル番号は 17 (11 hex);
(b) 証明書は DSA と SHA-1 ハッシュ・アルゴリズムで署名されています;
(c) 発行人の DN は OU=nist、O=gov、C=US です;
(d) サブジェクトの DN は OU=nist、O=gov、C=US です;
(e) 証明書は 1997 年 6 月 30 日 に発行され、有効期限は 1997 年 12 月 31 日までです;
(f) 証明書にはパラメータ付きの 1024 ビット のDSA 公開鍵が入っています;
(g) 証明書にはサブジェクト鍵識別子エクステンションが入っています; そして
(h) 証明書は CA 証明書です (基本制約エクステンションで示されているように)。

0000 30 82 02 b7 695: SEQUENCE
0004 30 82 02 77 631: . SEQUENCE tbscertificate
0008 a0 03 3: . . [0]
0010 02 01 1: . . . INTEGER 2 : 02
0013 02 01 1: . . INTEGER 17 : 11
0016 30 09 9: . . SEQUENCE
0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha : 2a 86 48 ce 38 04 03
0027 30 2a 42: . . SEQUENCE
0029 31 0b 11: . . . SET
0031 30 09 9: . . . . SEQUENCE
0033 06 03 3: . . . . . OID 2.5.4.6: C : 55 04 06
0038 13 02 2: . . . . . PrintableString 'US' : 55 53
0042 31 0c 12: . . . SET 0044 30 0a 10: . . . . SEQUENCE
0046 06 03 3: . . . . . OID 2.5.4.10: O : 55 04 0a
0051 13 03 3: . . . . . PrintableString 'gov' : 67 6f 76
0056 31 0d 13: . . . SET
0058 30 0b 11: . . . . SEQUENCE
0060 06 03 3: . . . . . OID 2.5.4.11: OU : 55 04 0b
0065 13 04 4: . . . . . PrintableString 'nist' : 6e 69 73 74
0071 30 1e 30: . . SEQUENCE
0073 17 0d 13: . . . UTCTime '970630000000Z' : 39 37 30 36 33 30 30 30 30 30 30 30 5a
0088 17 0d 13: . . . UTCTime '971231000000Z' : 39 37 31 32 33 31 30 30 30 30 30 30 5a
0103 30 2a 42: . . SEQUENCE
0105 31 0b 11: . . . SET
0107 30 09 9: . . . . SEQUENCE
0109 06 03 3: . . . . . OID 2.5.4.6: C : 55 04 06
0114 13 02 2: . . . . . PrintableString 'US' : 55 53
0118 31 0c 12: . . . SET
0120 30 0a 10: . . . . SEQUENCE
0122 06 03 3: . . . . . OID 2.5.4.10: O : 55 04 0a
0127 13 03 3: . . . . . PrintableString 'gov' : 67 6f 76
0132 31 0d 13: . . . SET
0134 30 0b 11: . . . . SEQUENCE
0136 06 03 3: . . . . . OID 2.5.4.11: OU : 55 04 0b
0141 13 04 4: . . . . . PrintableString 'nist' : 6e 69 73 74
0147 30 82 01 b4 436: . . SEQUENCE
0151 30 82 01 29 297: . . . SEQUENCE
0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa : 2a 86 48 ce 38 04 01
0164 30 82 01 1c 284: . . . . SEQUENCE
0168 02 81 80 128: . . . . . INTEGER : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
0299 02 14 20: . . . . . INTEGER : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 : 51 0d dc dd
0321 02 81 80 128: . . . . . INTEGER : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
0452 03 81 84 132: . . . BIT STRING (0 unused bits) : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78 : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13 : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77 : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91 : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14 : aa 71 e1
0587 a3 32 50: . . [3]
0589 30 30 48: . . . SEQUENCE
0591 30 0f 9: . . . . SEQUENCE
0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints : 55 1d 13
0598 01 01 1: . . . . . TRUE : ff
0601 04 05 5: . . . . . OCTET STRING : 30 03 01 01 ff
0608 30 1d 29: . SEQUENCE
0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier : 55 1d 0e
0615 04 16 22: . . . . . OCTET STRING : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff : 1c 21 e4 22 75 d6
0639 30 09 9: . SEQUENCE
0641 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha : 2a 86 48 ce 38 04 03
0650 03 2f 47: . BIT STRING (0 unused bits) : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68

D.2 証明書

本セクションは 730 バイトのバージョン 3 の注釈付きの 16 進 ダンプを示しています。この仕様書には下記の情報が含まれています。
(a) シリアル番号は 18 (12 hex) です;
(b) 証明書は DSA と SHA-1 ハッシュ・アルゴリズムで署名されます;
(c) 発行人の DN は OU=nist; O=gov; C=US です
(d) サブジェクトの DN は CN=Tim Polk; OU=nist; O=gov; C=US です
(e) 証明書は 1997 年 7 月 30 日から 1997 年 12 月 1 日まで有効です;
(f) 証明書には 1024 ビットの DSA 公開鍵が入っています;
(g) 基本制約エクステンションが存在しないので、証明書はエンド・エンティティ証明書です;
(h) 証明書には機関鍵識別子エクステンションが入っています;
(i) 証明書には一つの代替名称 (RFC 822 アドレス) が含まれています。

0000 30 82 02 d6 726: SEQUENCE
0004 30 82 02 96 662: . SEQUENCE
0008 a0 03 3: . . [0]
0010 02 01 1: . . . INTEGER 2 : 02
0013 02 01 1: . . INTEGER 18 : 12 0016 30 09 9: . . SEQUENCE
0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha : 2a 86 48 ce 38 04 03
0027 30 2a 42: . . SEQUENCE
0029 31 0b 11: . . . SET
0031 30 09 9: . . . . SEQUENCE 0033 06 03 3: . . . . . OID 2.5.4.6: C : 55 04 06
0038 13 02 2: . . . . . PrintableString 'US' : 55 53
0042 31 0c 12: . . . SET
0044 30 0a 10: . . . . SEQUENCE
0046 06 03 3: . . . . . OID 2.5.4.10: O : 55 04 0a
0051 13 03 3: . . . . . PrintableString 'gov' : 67 6f 76 0056 31 0d 13: . . . SET
0058 30 0b 11: . . . . SEQUENCE
0060 06 03 3: . . . . . OID 2.5.4.11: OU : 55 04 0b
0065 13 04 4: . . . . . PrintableString 'nist' : 6e 69 73 74
0071 30 1e 30: . . SEQUENCE
0073 17 0d 13: . . . UTCTime '970730000000Z' : 39 37 30 37 33 30 30 30 30 30 30 30 5a
0088 17 0d 13: . . . UTCTime '971201000000Z' : 39 37 31 32 30 31 30 30 30 30 30 30 5a
0103 30 3d 61: . . SEQUENCE
0105 31 0b 11: . . . SET
0107 30 09 9: . . . . SEQUENCE
0109 06 03 3: . . . . . OID 2.5.4.6: C : 55 04 06 0114 13 02 2: . . . . . PrintableString 'US' : 55 53
0118 31 0c 12: . . . SET
0120 30 0a 10: . . . . SEQUENCE
0122 06 03 3: . . . . . OID 2.5.4.10: O : 55 04 0a
0127 13 03 3: . . . . . PrintableString 'gov' : 67 6f 76 0132 31 0d 13: . . . SET
0134 30 0b 11: . . . . SEQUENCE
0136 06 03 3: . . . . . OID 2.5.4.11: OU : 55 04 0b 0141 13 04 4: . . . . . PrintableString 'nist' : 6e 69 73 74
0147 31 11 17: . . . SET
0149 30 0f 15: . . . . SEQUENCE
0151 06 03 3: . . . . . OID 2.5.4.3: CN : 55 04 03
0156 13 08 8: . . . . . PrintableString 'Tim Polk' : 54 69 6d 20 50 6f 6c 6b
0166 30 82 01 b4 436: . . SEQUENCE
0170 30 82 01 29 297: . . . SEQUENCE
0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa : 2a 86 48 ce 38 04 01
0183 30 82 01 1c 284: . . . . SEQUENCE
0187 02 81 80 128: . . . . . INTEGER : d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3 : 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2 : 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03 : 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6 : 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a : 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be : 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d : f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
0318 02 14 20: . . . . . INTEGER : a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83 : 51 0d dc dd
0340 02 81 80 128: . . . . . INTEGER : 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca : 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90 : d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5 : a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb : ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d : a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42 : 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90 : cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
0471 03 81 84 132: . . . BIT STRING (0 unused bits) : 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d : 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d : 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35 : c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6 : 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8 : 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44 : fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f : 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42 : 47 c6 43 0606 a3 3e 62: . . [3]
0608 30 3c 60: . . . SEQUENCE
0610 30 19 25: . . . . SEQUENCE
0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName : 55 1d 11
0617 04 12 18: . . . . . OCTET STRING : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 : 6f 76
0637 30 1f 31: . . . . SEQUENCE
0639 06 03 3: . . . . . OID 2.5.29.35: subjectAltName : 55 1d 23
0644 04 18 24: . . . . . OCTET STRING : 30 16 80 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa : d5 ff 1c 21 e4 22 75 d6
0670 30 09 9: . SEQUENCE
0672 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha : 2a 86 48 ce 38 04 03
0681 03 2f 47: . BIT STRING (0 unused bits) : 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58 : 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5 : 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94

D.3 RSA を使用したエンド・エンティティ証明書

本セクションは 675 バイトのバージョン 3 の注釈付きの 16 進 ダンプを示しています。この仕様書には下記の情報が含まれています。
(a) シリアル番号は 256 です;
(b) 証明書は RSA と MD2 ハッシュ・アルゴリズムで署名されます;
(c) 発行人の DN は OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de Catalunya; C=ES です
(d) サブジェクトの DN は CN=Francisco Jordan; OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de Catalunya; C=ES です
(e) 証明書は 1996 年 5 月 21 日に発行され、1997 年 5 月 21 日に期限切れとなりました;
(f) 証明書には 768 ビットの RSA 公開鍵が入っています;
(g) 証明書はエンド・エンティティ証明書です (CA 証明書ではありません);
(h) 証明書には代替サブジェクト名と代替発行人名 (どちらも URL) が含まれています;
(i) 証明書には機関鍵識別子エクステンションと証明書ポリシー・エクステンションが入っています;
(j) 証明書には、公開鍵がデジタル署名作成用であることを示すクリティカルな鍵用途エクステンションが含まれています。

0000 30 80 : SEQUENCE (size undefined)
0002 30 82 02 40 576: . SEQUENCE
0006 a0 03 3: . . [0]
0008 02 01 1: . . . INTEGER 2 : 02
0011 02 02 2: . . INTEGER 256 : 01 00
0015 30 0d 13: . . SEQUENCE
0017 06 09 9: . . . OID 1.2.840.113549.1.1.2: MD2WithRSAEncryption : 2a 86 48 86 f7 0d 01 01 02
0028 05 00 0: . . . NULL 0030 30 68 88: . . SEQUENCE
0032 31 0b 11: . . . SET 0034 30 09 9: . . . . SEQUENCE
0036 06 03 3: . . . . . OID 2.5.4.6: C : 55 04 06
0041 13 02 2: . . . . . PrintableString 'ES' : 45 53
0045 31 2d 45: . . . SET
0047 30 2b 43: . . . . SEQUENCE
0049 06 03 3: . . . . . OID 2.5.4.10: O : 55 04 0a
0054 13 24 36: . . . . . PrintableString 'Universitat Politecnica de Catalunya' : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c : 75 6e 79 61
0092 31 2a 42: . . . SET
0094 30 28 40: . . . . SEQUENCE
0096 06 03 3: . . . . . OID 2.5.4.11: OU : 55 04 0b
0101 13 21 33: . . . . . PrintableString 'OU=Dept. Arquitectura de Computadors' : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 : 73
0136 30 1e 30: . . SEQUENCE
0138 17 0d 13: . . . UTCTime '960521095826Z' : 39 36 30 37 32 32 31 37 33 38 30 32 5a
0153 17 0d 13: . . . UTCTime '979521095826Z' : 39 37 30 37 32 32 31 37 33 38 30 32 5a
0168 30 81 83 112: . . SEQUENCE
0171 31 0b 11: . . . SET
0173 30 09 9: . . . . SEQUENCE
0175 06 03 3: . . . . . OID 2.5.4.6: C : 55 04 06
0180 13 02 2: . . . . . PrintableString 'ES' : 45 53 0184 31 2d 12: . . . SET
0186 30 2b 16: . . . . SEQUENCE
0188 06 03 3: . . . . . OID 2.5.4.10: O : 55 04 0a
0193 13 24 36: . . . . . PrintableString 'Universitat Politecnica de Catalunya' : 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69 : 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c : 75 6e 79 61
0231 31 2a 42: . . . SET
0233 30 28 40: . . . . SEQUENCE
0235 06 03 3: . . . . . OID 2.5.4.11: OU : 55 04 0b 0240 13 21 33: . . . . . PrintableString 'Dept. Arquitectura de Computadors' : 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75 : 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72 : 73
0275 31 19 22: . . . SET
0277 30 17 20: . . . . SEQUENCE
0279 06 03 3: . . . . . OID 2.5.4.3: CN : 55 04 03
0284 13 10 16: . . . . . PrintableString 'Francisco Jordan' : 46 72 61 6e 63 69 73 63 6f 20 4a 6f 72 64 61 6e
0302 30 7c 2: . . SEQUENCE
0304 30 0d 13: . . . SEQUENCE
0306 06 09 9: . . . . OID 1.2.840.113549.1.1.1: RSAEncryption : 2a 86 48 86 f7 0d 01 01 01 0317 05 00 0: . . . . NULL 0319 03 6b 107: . . . BIT STRING : 00 (0 unused bits) : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63 : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33 : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9 : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78 : 56 15 c6 1c 8b 02 03 01 00 01
0428 a3 81 97 151: . . [3]
0431 30 3c 60: . . . SEQUENCE
0433 30 1f 31: . . . . SEQUENCE
0435 06 03 3: . . . . . OID 2.5.29.35: authorityKeyIdentifier : 55 1d 23
0440 04 14 22: . . . . . OCTET STRING : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf : 04 ea 04 c3
0464 30 19 25: . . . . SEQUENCE
0466 06 03 3: . . . . . OID 2.5.29.15: keyUsage : 55 1d 0f
0471 01 01 1: . . . . . TRUE
0474 04 04 4: . . . . . OCTET STRING : 03 02 07 80
0480 30 19 25: . . . . SEQUENCE
0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies : 55 1d 20
0487 04 21 33: . . . . . OCTET STRING : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05 : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01 : 0a
0522 30 1c 28: . . . . SEQUENCE
0524 06 03 3: . . . . . OID 2.5.29.17: subjectAltName : 55 1d 11
0529 04 15 21: . . . . . OCTET STRING : 30 13 86 11 68 74 74 70 3a 2f 2f 61 63 2e 75 70 : 63 2e 65 73 2f
0552 30 19 25: . . . . SEQUENCE
0554 06 03 3: . . . . . OID 2.5.29.18: issuerAltName : 55 1d 12
0559 04 12 18: . . . . . OCTET STRING : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75 : 70 63 2e 65
0579 30 80 : . SEQUENCE (indefinite length)
0581 06 07 7: . . OID
0583 05 00 0: . . NULL
0585 00 00 0: . . end of contents marker
0587 03 81 81 47: . BIT STRING : 00 (0 unused bits) : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50 : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91 : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
0637 00 00 0: . . end of contents marker

D.4 証明書失効リスト

本セクションは一つのエクステンション (cRLNumber) を有するバージョン 2 CRL の注釈付きの 16 進ダンプを示しています。CRL は 1996 年 7 月 7 日にOU=nist;O=gov;C=us で発行されました。次の発行予定は 1996 年 8 月 7 日でした。この CRL には、シリアル番号が 18 (12 hex) の一つの失効した証明書が入っています。CRL そのものの番号は 18 で、DSA と SHA-1 で署名されていました。

0000 30 81 ba 186: SEQUENCE
0003 30 7c 124: . SEQUENCE
0005 02 01 1: . . INTEGER 1 : 01
0008 30 09 9: . . SEQUENCE
0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha : 2a 86 48 ce 38 04 03
0019 30 2a 42: . . SEQUENCE
0021 31 0b 11: . . . SET
0023 30 09 9: . . . . SEQUENCE
0025 06 03 3: . . . . . OID 2.5.4.6: C : 55 04 06
0030 13 02 2: . . . . . PrintableString 'US' : 55 53
0034 31 0c 12: . . . SET
0036 30 0a 10: . . . . SEQUENCE
0038 06 03 3: . . . . . OID 2.5.4.10: O : 55 04 0a
0043 13 03 3: . . . . . PrintableString 'gov' : 67 6f 76
0048 31 0d 13: . . . SET
0050 30 0b 11: . . . . SEQUENCE
0052 06 03 3: . . . . . OID 2.5.4.11: OU : 55 04 0b
0057 13 04 4: . . . . . PrintableString 'nist' : 6e 69 73 74
0063 17 0d 13: . . UTCTime '970801000000Z' : 39 37 30 38 30 31 30 30 30 30 30 30 5a
0078 17 0d 13: . . UTCTime '970808000000Z' : 39 37 30 38 30 38 30 30 30 30 30 30 5a
0093 30 22 34: . . SEQUENCE
0095 30 20 32: . . . SEQUENCE
0097 02 01 1: . . . . INTEGER 18 : 12
0100 17 0d 13: . . . . UTCTime '970731000000Z' : 39 37 30 37 33 31 30 30 30 30 30 30 5a
0115 30 0c 12: . . . . SEQUENCE 0117 30 0a 10: . . . . . SEQUENCE
0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode : 55 1d 15
0124 04 03 3: . . . . . . OCTET STRING : 0a 01 01
0129 30 09 9: . SEQUENCE
0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha : 2a 86 48 ce 38 04 03
0140 03 2f 47: . BIT STRING (0 unused bits) : 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9 : 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea : 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2

 

付録 E. 著者のアドレス

Russell Housley
SPYRUS
381 Elden Street
Suite 1120
Herndon, VA 20170
USA

EMail: housley@spyrus.com

Warwick Ford
VeriSign, Inc.
One Alewife Center
Cambridge, MA 02140
USA

EMail: wford@verisign.com

Tim Polk
NIST
Building 820, Room 426
Gaithersburg, MD 20899
USA

EMail: wpolk@nist.gov

David Solo
Citicorp
666 Fifth Ave, 3rd Floor
New York, NY 10103
USA

EMail: david.solo@citicorp.com

 

付録 F. 著作権表示全文

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.