4 <- index -> 6


5.  CRL および CRL 拡張のプロファイル English

前記で検討したように、この X.509 v2 CRL プロファイルのひとつの目標は、「相互運用可能かつ再利用可能(reusable)なインターネット PKI の構築を促進すること」である。この目標を達成するため、拡張の利用のためのガイドラインが規定され、いくつかの想定が、その CRL 中に含まれる情報の性格について設けられる。

CRL は、相互運用可能性目標の広範な spectrum や、運用的要件や保証要件について、さらに広範囲を扱う広範なアプリケーションや環境において使われる可能性がある。このプロファイルは、広範な相互運用可能性を要する一般的なアプリケーションのための共通 baseline を確立する。このプロファイルは、すべての CRL において期待されうる情報のセットを規定する。また、このプロファイルは、頻繁に使われる属性用と共に、これらの属性の共通表現用に、CRL 内に共通の場所を規定する。

CRL 発行者 は、CRL を発行する。この CRL 発行者 は、その CA か、あるいは、その CA によって CRL を発行することを認可されてきた主体のいずれかである。CA は、彼らが発行した証明書についての状態情報を提供するために CRL を発行する。しかし、CA は、この責任を別の信頼された(trusted)機関(authority)に依託する可能性がある。

各 CRL は、特定の範囲をもつ。この CRL の範囲は、所与の CRL 上に現れる可能性がある証明書のセットである。例えば、その範囲(scope)は、「CA X によって発行されたすべての証明書」、「CA X によって発行されたすべての CA 証明書」、「鍵の侵害や CA の侵害の理由によって失効されている CA X によって発行されたすべての証明書」もしくは「Boulder 拠点に在籍する NIST 職員宛に発行されたすべての証明書」のような、任意のローカル情報に基づく証明書の集合である可能性がある。

complete CRL は、すべての期限切れとなっていない証明書を掲げ、その範囲内に、その CRL の範囲内の失効理由のひとつによって失効されたものを掲げる。full かつ complete CRL は、ある CA によって発行されて、既に何らかの理由で失効された、すべての期限切れとなっていない証明書を掲げる。(「CA および CRL 発行者は、名前によって識別されるので、ある CRL の範囲は、その CRL に署名するために使われる鍵、もしくは、証明書に署名するために使われた鍵によって影響を受けないこと」に注意。)

CRL の範囲 がその CRL 発行者以外の主体によって発行された、ひとつもしくは複数の証明書を含む場合、これは、indirect CRL である。間接的 CRL の範囲は、単一の CA によって発行された証明書に制限される可能性、あるいは、複数の CA によって発行された証明書を含む可能性がある。その indirect CRL の発行者が CA である場合、その indirect CRL の範囲は、その CRL の発行者によって発行された証明書も含む可能性がある(MAY)

その CRL 発行者は、delta CRL も生成する可能性がある(MAY)。delta CRL は、それらの証明書のみを掲げ、その範囲内で、その失効状態は、参照される complete CRL の発行以降に変更されたものである。この参照される complete CRL は、base CRL と呼ばれる。delta CRL の範囲は、これが参照する base CRL と同一でなければならない(MUST)

このプロファイルは、ひとつのプライベートインターネット CRL 拡張を規定するが、いかなるプライベート CRL エントリ拡張も規定しない。

追加的な要件あるいは特別な目的要件をもつ環境は、このプロファイルに基づいて構築される可能性、あるいは、これを置き換える可能性がある。

準拠する CA は、他の失効メカニズムもしくは 証明書状態メカニズムが提供される場合、CRL を発行することを要求されない。CRL が発行されるとき、その CRL は、v2 CRL でなければならない(MUST)。次の CRLが発行される拠となる日付を nextUpdate フィールド(5.1.2.5 節)中に含まなければならない(MUST)。CRL 番号拡張(5.2.3 節)を含まなければならない(MUST)。そして、authority 鍵識別子拡張(5.2.1 節)を含まなければならない(MUST)。CRL をサポートする準拠するアプリケーションは、ひとつの CA によって発行されたすべての証明書についての失効情報を提供する v1 および v2 の complete CRL の両方を処理することを要する(REQUIRED)。準拠するアプリケーションには、ある CA によって発行されたすべての証明書以外の範囲(scope)をもつ delta CRL、間接 CRL もしくは CRL の処理をサポートすることは要求されない。

5.1. CRL フィールド English

X.509 v2 CRL syntax は、下記のとおり。署名の計算について、署名されるデータは、ASN.1 DER に符号化される。ASN.1 DER の符号化は、各要素についての tag、length、value 符号化システムである。


   CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

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

   -- Version, Time, CertificateSerialNumber, and Extensions
   -- are all defined in the ASN.1 in Section 4.1

   -- AlgorithmIdentifier is defined in Section 4.1.1.2

下記の要素は、インターネット PKI における X.509 v2 CRL の利用を記述する。

5.1.1. CertificateList フィールド English

CertificateList は、3 つの required フィールドの SEQUENCE である。このフィールドについては、下記の節に詳細に記述されている。

5.1.1.1. tbsCertList English

the sequence における最初のフィールドは、tbsCertList である。このフィールド自体は、その発行者の名前、発行日、次のリストの発行日、失効された証明書の オプションとしてのリスト、および オプションとしての CRL 拡張を含む sequence である。失効された証明書が無いとき、その失効された証明書リストは、不在となる。ひとつもしくは複数の証明書が失効されるとき、その失効された証明書リスト上の各エントリは、ユーザ証明書のシリアル番号、失効日付およびオプションとしての CRL エントリ拡張の sequence によって規定される。

5.1.1.2. signatureAlgorithm English

signatureAlgorithm フィールドは、CertificateList に署名するために、その CRL 発行者によって使われるアルゴリズムについてのアルゴリズム識別子を含む。このフィールドは、AlgorithmIdentifier type のものである。これは、4.1.1.2 節に定義されている。[RFC3279]、[RFC4055] および [RFC4491] は、この仕様についてサポートされているアルゴリズムを掲げるが、他の署名アルゴリズムも、サポートされる可能性がある(MAY)

このフィールドは、sequence tbsCertList(5.1.2.2 節)中の署名フィールドと同一のアルゴリズム識別子を含まなければならない(MUST)

5.1.1.3. signatureValue English

signatureValue フィールドは、その ASN.1 DER 符号化された tbsCertList に基づいて計算されるディジタル署名を含む。その ASN.1 DER encoded tbsCertList は、 その署名関数に対する input として使われる。この署名の値は、BIT STRING として符号化され、CRL signatureValue フィールド中に含められる。このプロセスの詳細は、[RFC3279], [RFC4055] および [RFC4491] においてサポートされるアルゴリズムの各々について規定される。

CRL 発行者でもある CA は、ひとつのプライベート 鍵を証明書および CRL にディジタル署名するために使う可能性がある(MAY)か、あるいは、分離されたプライベート鍵を、証明書および CRL にデジタル的に署名するために使う可能性がある(MAY)。分離されたプライベート鍵が採用されるとき、これらのプライベート鍵と関連づけられた各々の公開鍵は、分離された証明中に配置される。(ひとつは、keyCertSign bit が鍵用途拡張中にセットされてるものであり、もうひとつは、cRLSign bit が鍵用途拡張 (4.2.1.3 節)中にセットされてるもの。)分離されたプライベート鍵が採用されるとき、その CA によって発行された証明書は、ある authority 鍵識別子を含み、対応する CRL は、異なる authority 鍵識別子を含む。証明書の署名の検証および CRL 署名の検証について、分離された CA 証明書の利用は、向上されたセキュリティの特徴を提供できる。; しかし、これは、アプリケーションに負荷をもたらし、これは、相互運用可能性を制限する可能性がある。多くのアプリケーションは、証明書パスを構築し、その証明書パスを検証する(6 章)。CRL checking は、逆に、分離されている証明書パスが構築されて、その CA の CRL 署名検証証明書について検証されることを要求する。CRL checking を行うアプリケーションは、証明書および CRL が同一の CA プライベート鍵でデジタル的に署名されるとき、証明書パス検証をサポートしなければならない(MUST)。これらのアプリケーションは、証明書および CRL が異なる CA プライベート鍵でディジタル署名されるとき、証明書パス検証をサポートする必要がある(SHOULD)

5.1.2. 証明書 List "To Be Signed" English

署名されるべき証明書リスト、もしくは TBSCertList は、required フィールドおよび オプションとしてのフィールドの sequence である。その要求されるフィールドは、その CRL 発行者、その CRL に署名するために使われたアルゴリズム、および、その CRL が発行された日時を識別する。

オプションとしてのフィールドは、日時を含み、これによって、その CRL 発行者は、next CRL、失効された証明書のリストおよび CRL 拡張を発行する。その失効された証明書リストは、ある CA が既に発行した、いかなる有効期限をむかえていない証明書も失効していなかった場合をサポートするためのオプションとしてのものである。このプロファイルは、準拠する CRL 発行者に、すべての発行された CRL 中に nextUpdate フィールドおよびその CRL 番号およびauthority 鍵識別子 CRL 拡張を含めることを要求する。

5.1.2.1. バージョン English

このオプションとしてのフィールドは、その符号化された CRL のバージョンを記述する。このプロファイルによって要求されるように拡張が使われるとき、このフィールドが、存在しなければならない(MUST)。そして、バージョン 2(その整数値は 1)を規定しなければならない(MUST)

5.1.2.2. 署名 English

このフィールドは、その CRLに署名するために使われるアルゴリズムについての識別子を含む。[RFC3279]、[RFC4055] および [RFC4491] は、インターネット PKI において使われる最も普及している(popular)署名アルゴリズムについての OID を掲げる。

このフィールドは、sequence CertificateList(5.1.1.2節)中の signatureAlgorithm フィールドと同一のアルゴリズム識別子を含まなければならない(MUST)

5.1.2.3. 発行者名 English

発行者名は、その CRL に署名して発行した主体を識別する。その 発行者のアイデンティティは、その発行者フィールドにおいて運ばれる。代替名の形態は、issuerAltName 拡張 (5.2.2 節)にもある可能性がある。その発行者 フィールドは、空でない X.500 DN(Distinguished Name)を含まなければならない(MUST)。その発行者フィールドは、X.501 type Name として規定されており、その証明書中の発行者名フィールド(4.1.2.4 節)用の符号化ルールに従わなければならない(MUST)

5.1.2.4. This Update English

このフィールドは、この CRL の発行日を示す。thisUpdate は、UTCTime もしくは GeneralizedTime として符号化される可能性がある。

このプロファイルに準拠する CRL 発行者は、thisUpdate を 2049 年までの日付について UTCTime として符号化しなければならない(MUST)。このプロファイルに準拠する CRL 発行者は、thisUpdate を 2050 年以降の日付について、GeneralizedTime として符号化しなければならない(MUST)。準拠するアプリケーションは、UTCTime か、あるいは GeneralizedTime のいずれかに符号化された日付を処理できなければならない(MUST)

UTCTime として符号化される場合、thisUpdate は、4.1.2.5.1 節に規定されているように定義され、解釈されなければならない(MUST)。GeneralizedTime として符号化される場合、thisUpdate は、4.1.2.5.2 節に定義されているように規定され、解釈されなければならない(MUST)

5.1.2.5. Next Update English

このフィールドは、日付を示し、これによって、the next CRL が発行される。その next CRL は、示された日付前に発行される可能性があるが、これは、示された日付より後では発行されない。CRL 発行者は、すべての以前の CRL と等しい、あるいは、以降の nextUpdate 時刻をもつ CRL を発行する必要がある(SHOULD)。nextUpdate は、UTCTime もしくは GeneralizedTime として符号化される可能性がある。

Conforming CRL 発行者は、すべての CRL 中に nextUpdate フィールドを含まなければならない(MUST)。「TBSCertList の ASN.1 構文は、このフィールドを OPTIONAL として記述すること。(これは、[X.509] に定義されている ASN.1 構造体で制約されている。)」に注意。nextUpdate を省略する CRL を処理するクライアントの振るまいは、このプロファイルにいって規定されていない。

このプロファイルに準拠する CRL 発行者は、nextUpdate を 2049 年までの日付について UTCTime として符号化しなければならない(MUST)。このプロファイルに準拠する CRL 発行者は、nextUpdate を 2050 年以降の日付について、GeneralizedTime として符号化しなければならない(MUST)。準拠するアプリケーションは、UTCTime か、あるいは、GeneralizedTime のいずれかに符号化された日付を処理できなければならない(MUST)

UTCTime として符号化される場合、nextUpdate は、4.1.2.5.1 節に定義されているように規定され、解釈されなければならない(MUST)。GeneralizedTime として符号化される場合、nextUpdate は、4.1.2.5.2 節に定義されているように規定され、解釈されなければならない(MUST)

5.1.2.6. 失効された証明書s English

失効された証明書が無いとき、その失効された証明書リストは、あってはならない(MUST)。さもなくば、失効された証明書は、それらのシリアル番号によって掲載される。その CA によって失効された証明書は、その証明書のシリアル番号によって一意に識別される。その失効が発生した日付は、規定される。revocationDate についての時刻は、5.1.2.4 節に記述されているように、表現されなければならない(MUST)。追加的な情報が、CRL エントリ拡張において提供される可能性がある。; CRL エントリ拡張は、5.3 節において検討される。
 

5.1.2.7. 拡張 English

このフィールドは、そのバージョンが 2(5.1.2.1 節)である場合にのみ現れる可能性がある。ある場合、このフィールドは、ひとつ、もしくは、複数の CRL 拡張の sequence である。CRL 拡張は、5.2 節において検討される。

5.2. CRL 拡張 English

ANSI X9、ISO/IEC および ITU-T for X.509 v2 CRL [X.509] [X9.55] によって規定された拡張は、追加的な属性を CRL と関連づけるための手法を提供する。X.509 v2 CRL フォーマットも、communities が、それらの communities に固有な情報を運ぶためにプライベート拡張を規定できるようにする。CRL 中の各拡張は、critical もしくは非-critical として、設計される可能性がある。ある CRL が、そのアプリケーションが処理できない critical 拡張を含む場合、そのアプリケーションは、その CRL を証明書の状態を判定するために使ってはならない(MUST NOT)。しかし、アプリケーションは、解釈できない非-critical 拡張を無視する可能性がある。下記の節は、Internet CRL 内で使われるこれらの拡張を提供する。Communities は、拡張をこの仕様中に定義されていない CRL に含めることを選択する可能性がある。しかし、一般的な文脈(context)において使われる可能性がある CRL 中のあらゆる critical 拡張を採用する際には警戒する必要がある。

準拠する CRL 発行者には、「発行されたすべての CRL 中に authority 鍵識別子(5.2.1 節)および CRL number(5.2.3 節) 拡張を含むこと」が要求される(REQUIRED)

5.2.1. Authority 鍵識別子 English

authority 鍵識別子拡張は、ある CRL に署名するために使われたプライベート鍵 に対応する公開鍵を識別するための手段を提供する。その識別は、その鍵識別子(その CRL 署名者の証明書中の subject 鍵識別子)か、あるいは、発行者名およびシリアル番号のいずれかに基づくことができる。この拡張は、複数の同時生成された鍵ペアか、あるいは、changeover のいずれかによって、発行者が複数の署名鍵をもつ場合、特に有用である。

準拠する CRL 発行者は、その鍵識別子の手法を使わなければならない(MUST)。そして、この拡張を発行されたすべての CRL 中に含まなければならない(MUST)

この CRL 拡張についての構文は、4.2.1.1 節に規定されている。

5.2.2. 発行者代替名 English

発行者代替名拡張は、追加的なアイデンティティが、その CRL の発行者 と関連つけられることをできるようにする。定義されたオプションは、電子メールアドレス(rfc822Name)、DNS 名、IP アドレスおよび URI を含む。単一の名前形態および複数の名前形態の複数の instances が、含まれる可能性がある。このような識別子が使われている限り、発行者代替名拡張は、使われなければならない(MUST)。; しかし、DNS 名は、4.1.2.4 節に記述されているように、domainComponent 属性を使って発行者フィールド中に表現される可能性がある(MAY)

準拠する CRL 発行者は、issuerAltName 拡張に非 critical として印をつける必要がある(SHOULD)

この CRL 拡張についての OID および構文は、4.2.1.7 節に規定されている。

5.2.3. CRL 番号 English

CRL 番号は、所与の CRL 範囲(scope)および CRL 発行者についての単調増加するシーケンス番号を運ぶ非-critical CRL 拡張である。この拡張は、ユーザが、ある特定の CRL が別の CRL に 取って代わるとき、容易に判定できるようにする。CRL 番号も、相補的な complete CRL および delta CRL の識別をサポートする。このプロファイルに準拠する CRL 発行者は、この拡張を、すべての CRL の中に含まなければならない(MUST)。そして、この拡張に非-critical として印をつけなければならない(MUST)

CRL 発行者が所与の範囲(scope)についての complete CRL に加えて delta CRL を生成する場合、その complete CRL および delta CRL は、ひとつの採番 sequence を共有しなければならない(MUST)。同一の範囲 を対象とする delta CRL および complete CRL が同時刻に発行される場合、それらは、同一の CRL 番号をもたなければならない(MUST)。そして、同一の失効情報を提供しなければならない(MUST)。すなわち、その delta CRL と 、許容可能な complete CRL の組み合わせは、同時に発行された complete CRL と同一の失効情報を提供しなければならない(MUST)

CRL 発行者が異なる時刻に、同一の範囲(scope)について、ふたつの CRL(ふたつの complete CRL、ふたつの delta CRL、あるいは、complete CRL および delta CRL)を生成する場合、その 2 つの CRL は、同一の CRL 番号をもってはならない(MUST NOT)。すなわち、その 2 つの CRL 中の、この update フィールド(5.1.2.4 節)が一致しない場合、その CRL 番号は、異ならなければならない(MUST)

上記の要件が与えられたとして、CRL 番号は、long integer を含むことが期待される可能性がある。CRL verifier は、20 octet までの CRLNumber 値扱うことができなければならない(MUST)。準拠する CRL 発行者は、20 octet より長い CRLNumber 値を使ってはならない(MUST NOT)

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

CRLNumber ::= INTEGER (0..MAX)

5.2.4. Delta CRL Indicator English

delta CRL 表示子は、CRL を delta CRL であるとして識別する critical CRL 拡張である。Delta CRL は、complete CRL に現れるすべての情報ではなく、以前に配布した失効情報に対する updates を含む。delta CRL の利用は、環境によっては、ネットワーク負荷および処理時間を著しく低減できる。Delta CRL は、一般に、それらが更新する CRL より小さいので、delta CRL を取得するアプリケーションは、対応する complete CRL を取得するアプリケーションよりは少ないネットワーク帯域しか消費しない。CRL 構造体以外のフォーマットで失効情報を保存するアプリケーションは、新しい失効情報を、そのローカルのデータベースに情報を処理させることなく追加できる。

delta CRL 表示子拡張は、type BaseCRLNumber の単一の値を含む。その CRL 番号は、この delta CRL の生成における起点として使われていた(所与の範囲について完全な)CRL を識別する。準拠する CRL 発行者は、その参照される base CRL を complete CRL として発行しなければならない(MUST)。その delta CRL は、その同一範囲についての失効状態に対する、すべての updates を含む。delta CRL と、その参照される base CRL の組み合わせは、その delta CRL の発行の時点における(許容可能な範囲 についての)complete CRL と等価である。

準拠する CRL 発行者が delta CRL を生成するとき、その delta CRL は、critical delta CRL 表示子拡張を含まなければならない(MUST)

delta CRL が発行されるとき、これは、同一理由をもつ集合、および、それが参照する base CRL によって対象範囲とされた証明書の同一の集合を網羅しなければならない(MUST)。すなわち、その delta CRL の範囲は、その base として参照される complete CRL の範囲と同一でなければならない(MUST)。参照される base CRL および delta CRL は、その発行する配布点拡張を省略するか、あるいは、同一の発行配布点拡張を含まなければならない(MUST)。さらに、その CRL 発行者は、更新するために使える delta CRL、および、あらゆる complete CRLに署名するために同一のプライベート鍵を使わなければならない(MUST)

delta CRL をサポートするアプリケーションは、その範囲についての delta CRL を、その範囲について完全である issued CRL と組み合わせることによって、所与の範囲について完全である CRL か、あるいは、その範囲について完全な、ローカルで作成された CRL のいずれかを構築できる。

delta CRL が complete CRL もしくはローカルで構築された CRL と組み合わされるとき、結果としてローカルに構築される CRL は、その構築において使われる delta CRL 中にある CRL 番号拡張中に規定される CRL 番号をもつ。さらに、その結果としてローカルで構築された CRL は、その構築において使われた delta CRL の対応するフィールド中に規定される thisUpdate および nextUpdate 時刻をもつ。さらに、そのローカルで構築された CRL は、その delta CRL から、その issuing 配布点 を継承する。

complete CRL および delta CRL は、下記の 4 つの条件が満たされる場合、組み合わされる可能性がある(MAY)。:

(a) complete CRL および delta CRL は、同一の発行者をもつ。

(b) complete CRL および delta CRL は、同一の範囲をもつ。その 2 CRL は、下記の条件のいずれかが合致する場合、同一の範囲をもつ。:

(1) issuingDistributionPoint 拡張は、complete CRL および delta CRL の両方から省略される。

(2) issuingDistributionPoint 拡張は、その complete CRL と delta CRL の両方の中に存在し、その拡張中のフィールドの各々についての値は、両 CRL において同一である。

(c) complete CRL の CRL 番号は、その delta CRL 内で規定された BaseCRLNumber 以上である。すなわち、その complete CRL は、(少なくとも) 参照される base CRL によって保持されている、すべての失効情報を含む。

(d) complete CRL の CRL 番号は、その delta CRL の CRL 番号より小さい。すなわち、その delta CRL は、その採番 sequence 中の complete CRL に従う。

CRL 発行者は、「ある delta CRL と、あらゆる適切な complete CRL の組み合わせが、現在の失効状態を正確に反映すること」を確保しなければならない(MUST)。その CRL 発行者は、その参照される base CRL の生成によって状態が変更された delta CRL の範囲内の各証明書について、その delta CRL 中にエントリを含まなければならない(MUST)。:

(a) その証明書が、その CRL の範囲中に含まれる理由で失効される場合、その証明書を失効されたものとして掲げる。

(b) その証明書が有効であり、かつ、参照される base CRL 上か、以降のいずれかの CRL 上に理由コード certificateHold と共に掲げられるか、かつ、理由コード certificateHold が、その CRL の範囲中に含められている場合、その証明書をその理由コード removeFromCRL と共に掲げる。

(c) その証明書が、その CRL の範囲外の理由によって失効されているが、その証明書は、その参照される base CRL 上か、いかなる以降の CRL 上に、この CRL の範囲内に含められた理由コードと共に掲げられた場合、その証明書を失効されたものとして掲げるが、その理由コードを省略する。

(d) その証明書がその CRL の範囲外の理由によって失効されており、かつ、その証明書がその参照される base CRL 上にも、いかなる以降の CRL 上にも、この CRL の範囲内に含まれる理由コードと共に掲げられなかった場合、その証明書を、この CRL 上に掲げない。

ある証明書の状態は、それが(certificateHold を含む何らかの失効理由によって)失効されている場合、それが保持(hold)から解放される場合、あるいは、その失効理由が変更される場合、変更されたと見なされる。

たとえ証明書が、参照された base CRL 中に保持されていなかった場合にも、その証明書を delta CRL上の理由コード removeFromCRL と共に掲げることが、適切である。その証明書が base 以降、この delta CRL 前に発行された、いずれかの CRL 中の hold 上に置かれ、それから hold から解放された場合、それは、その delta CRL 上に失効理由 removeFromCRL と共に掲げられなければならない(MUST)

CRL 発行者は、その証明書中に規定されている notAfter time が、その delta CRL 中に規定された thisUpdate time 以前であり、かつ、その証明書が、その参照される base CRL 上、あるいは、base 以降、この delta CRL 前に発行された、いずれかの CRL 中に掲げられた場合、delta CRL 上の証明書を理由コード removeFromCRL と共にオプションとして掲げる可能性がある(MAY)

証明書失効通知が、ある delta CRL 上に初めて現れる場合、その証明書について、同一の範囲(scope)についての next complete CRL より前に期限が切れる有効期間が発行される可能性がある。この場合、その失効通知は、その失効通知が、少なくとも、この範囲について明示的に発行された、ひとつの complete CRL の上に含められるまで、すべての以降の delta CRL 中に含まれなければならない(MUST)

delta CRL をサポートするアプリケーションは、現在の complete CRL を、以前に発行された complete CRL と、最近の delta CRL を組み合わせることによって構築できなければならない(MUST)。delta CRL をサポートするアプリケーションは、以前にローカルで構築された complete CRL と、現在の delta CRL 組み合わせることによって、現在の complete CRL も構築できる可能性がある(MAY)。delta CRL は、現在時刻が thisUpdate フィールドおよび nextUpdate フィールドの中に収められた時刻の間ある場合、現在のものであると見なされる。環境によっては、その CRL 発行者は、nextUpdate フィールドによって示された時刻の前に、ひとつ、もしくは、複数の delta CRL を発行する可能性がある。所与の範囲(scope)について、ひとつより多くの現在の delta CRL に遭遇した場合、そのアプリケーションは、最新の値を最新のものとなるように、thisUpdate中にもつものを考慮する必要がある(SHOULD)

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

BaseCRLNumber ::= CRLNumber

5.2.5. Issuing 配布点 English

配布点を発行することは、その CRL 配布点と、特定の CRL についての範囲を識別する critical CRL 拡張である。そして、これは、「その CRL は、end entity 証明書のみ、CA 証明書のみ、属性証明書のみ、あるいは、理由コードの限定された集合についての失効を対象範囲とするか否か?」を示す。この拡張は、critical ではあるが、準拠する実装は、この拡張をサポートすることを要しない。しかし、この拡張をサポートしない実装は、この CRL に掲げられていない、あらゆる証明書の状態を unknown として扱うか、あるいは、いかなる解釈されない critical 拡張も収めていない別の CRL を配置するか、のいずれかをしなければならない(MUST)

その CRL は、CRL 発行者のプライベート鍵を使って署名される。CRL 配布点は、それら自身の鍵ペアをもたない。その CRL が X.500 ディレクトリ中に保管される場合、これは、その CRL 配布点に対応する directory エントリ中に保管される。これは、その CRL 発行者のディレクトリエントリとは異なる可能性がある。

ある配布点に関連づけられた理由コードは、onlySomeReasons 中に規定されなければならない(MUST)。onlySomeReasons が現れない場合、その配布点は、すべての理由コードについて、失効を含まなければならない(MUST)。CA は、その CRL を侵害や、定期的な失効に基づいて分割するための CRL 配布点を使う可能性がある。この場合、理由コード keyCompromise (1)、cACompromise (2) および aACompromise (8) を伴う失効は、ある配布点に現れ、他の理由コードを伴う失効は、別の配布点に現れる。

CRL が onlySomeReasons の存在を伴う issuingDistributionPoint 拡張を含む場合、失効された CRL の範囲中のすべての証明書には、「規定されていない(unspecified)」以外の失効理由が割り当てられなければならない(MUST)。その割り当てられた失効理由は、「どの CRL に失効された証明書を掲げるか?」を判定するために使われる。しかし、reasonCode CRL エントリ拡張を対応する CRL エントリ中に含める要件は無い。

distributionPoint フィールドについての構文および semantics は、cRLDistributionPoints 拡張 ( 4.2.1.13 節)中の distributionPoint フィールドについてと同様である。distributionPoint フィールドがある場合、これは、少なくとも、この CRL の対象範囲内にあるすべての証明書のcRLDistributionPoints 拡張の対応する distributionPoint フィールドからの名前のひとつを含まなければならない(MUST)。同一の符号化は、その証明書および CRL の distributionPoint フィールドにおいて使われなければならない(MUST)

distributionPoint フィールドが無い場合で、CRL は、その CRL 発行者によって発行されたすべての revoked unexpired 証明書用のエントリがある場合、それを、その CRL の範囲内に含まなければならない(MUST)

その CRL の範囲がその CRL 発行者によって発行された証明書のみを含む場合、その indirectCRL boolean は、FALSE にセットされなければならない(MUST)。さもなくば、その CRL の範囲が、その CRL 発行者以外の、ひとつもしくは複数の authorities によって発行された証明書を含む場合、その indirectCRL boolean は、TRUE にセットされなければならない(MUST)。各 エントリについて責任を負う authority は、証明書発行者 CRL エントリ拡張 (5.3.3 節)によって示される。

その CRL の範囲 が end entity の公開鍵証明書のみを含む場合、onlyContainsUserCerts は、TRUE にセットされなければならない(MUST)。その CRL の範囲が CA 証明書のみを含む場合、onlyContainsCACerts は、TRUE にセットされなければならない(MUST)。onlyContainsUserCerts か、あるいは、onlyContainsCACerts のいずれかが TRUE にセットされる場合、その CRL の範囲は、いかなる v1 もしくは v2 証明書も含んではならない(MUST NOT)。準拠する CRL 発行者は、onlyContainsAttributeCerts boolean に FALSE をセットしなければならない(MUST)

準拠する CRL の発行者は、issuing 配布点拡張の DER 符号化されたものが空の sequence である場合、CRL を発行してはならない(MUST NOT)。すなわち、onlyContainsUserCerts、onlyContainsCACerts、indirectCRL および onlyContainsAttributeCerts が、すべて FALSE である場合、distributionPoint フィールドか、あるいは、onlySomeReasons フィールドのいずれかが、存在しなければならない(MUST)

   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,
        onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

        -- at most one of onlyContainsUserCerts, onlyContainsCACerts,
        -- and onlyContainsAttributeCerts may be set to TRUE.

 

5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution Point)English

最新の CRL 拡張は、「どのように、この complete CRL についての delta CRL 情報は、取得されているか?」を識別する。準拠する CRL 発行者は、この拡張に非-critical と印をつけなければならない(MUST)。この拡張は、delta CRL 中にあってはならない(MUST NOT)

同一の構文は、この拡張のために cRLDistributionPoints 証明書拡張として使われ、4.2.1.13 節中に記述されている。しかし、配布点フィールドのみが、この文脈において、有意である。その理由および cRL発行者のフィールドは、この CRL 拡張から省略されなければならない(MUST)

各配布点名は、この complete CRL についての delta CRL を見つけることができる位置情報を提供する。これらの delta CRL の範囲は、この complete CRL の範囲と同様でなければならない(MUST)。この CRL 拡張の内容は、delta CRL を配置するためにのみ使われる 。; その内容は、その CRL、もしくは、その参照された delta CRL を検証するために使われない。配布点について 4.2.1.13 節 において定義された符号化の慣行は、この拡張に適用される。

id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }

FreshestCRL ::= CRLDistributionPoints

5.2.7. Authority 情報アクセス English

この節は、CRL 中の Authority 情報 Access 拡張の利用を規定する。証明書の拡張について 4.2.2.1節に規定された構文および semantics は、CRL 拡張にも使われる。

この CRL 拡張は、非-critical として印をつけられなければならない(MUST)

CRL 中にあるとき、この拡張は、少なくとも、id-ad-caIssuers をその accessMethod として規定している、ひとつの AccessDescription を含まなければならない(MUST)。id-ad-caIssuers OID は、入手可能な情報が、その CRL 上の署名を検証するために使える証明書(すなわち、その CRL 上の発行者名と一致する subject 名をもつ証明書、および、その CRL に署名するために使われたプライベート鍵と対応する subject 公開鍵をもつ証明書)を掲げるとき、使われる。id-ad-caIssuers 以外のアクセス手法種別は、含まれてはならない(MUST NOT)。少なくとも、AccessDescription の一例は、HTTP [RFC2616] の URI もしくは LDAP [RFC4516] の URI である accessLocation を規定する必要がある(SHOULD)

その情報が HTTP もしくは FTP、accessLocation 経由で入手可能な場所は、uniformResourceIdentifier でなければならない(MUST)。そして、その URI は、[RFC2585] で規定されているように単一の DER で符号化された証明書か、あるいは、[RFC2797] で規定されているように BER もしくは DER で符号化された"certs-only" CMS メッセージ中の証明書の collection のいずれかを指さなければならない(MUST)

証明書にアクセスするために HTTP あるいは FTP をサポートする準拠するアプリケーションは、個々の DER で符号化された証明書を受容できなればならない(MUST)。そして、"certs-only" CMS メッセージを許容できる必要がある(SHOULD)

その URI 経由でアクセスされる HTTP サーバ実装は、単一の DER で符号化された証明書についての response の content-type header フィールド中に media type アプリケーション/pkix-cert [RFC2585] を規定する必要がある(SHOULD)。そして、"certs-only" CMS メッセージについての response の content-type header フィールド中に media type アプリケーション/pkcs7-mime [RFC2797] を規定する必要がある(SHOULD)。FTP について、single DER encoded 証明書 を含むファイルの名前は、".cer"という suffix [RFC2585] をもつ必要がある(SHOULD)。そして、"certs-only" CMS メッセージを含むファイルの名前は、".p7c" という suffix [RFC2797] をもつ必要がある(SHOULD)。準拠するクライアントは、その content のヒントとして media type or file 拡張を使う可能性があるが、そのサーバ response 中の正しい media type もしくは file 拡張の存在にのみ依存しきってはいけない。

accessLocation が directoryName であるとき、その情報は、どのようなディレクトリサーバがローカルで設定されているのであれ、そのから、そのアプリケーションによって取得されるべきものである。ある CA 公開鍵が証明書および CRL 上の署名を検証するために使われるとき、その desired CA 証明書は、[RFC4523] に規定されているように crossCertificatePair 属性中、かつ/または、cACertificate 属性中に保管される。異なる公開鍵が証明書および CRL 上の署名を検証するために使われるとき、その desired 証明書は、[RFC4523] において規定されているように、userCertificate 属性中に保管される。それゆえ、accessLocation 形態の directoryName をサポートする実装は、 これらの 3 つの属性のいずれか中に必要とされた証明書を発見することに備えなければならない(MUST)。アプリケーションが、そのディレクトリ(例: DAP もしくは LDAP) にアクセスするために使うプロトコルは、ローカルな問題である。

その情報が LDAP 経由で入手可能な場合、その accessLocation は、uniformResourceIdentifierである必要がある(SHOULD)。LDAP URI [RFC4516] は、その証明書を保持しているエントリの DN を収めた <dn> フィールドを含まなければならない(MUST)。また、DER で符号化された証明書もしくは横断証明書のペア [RFC4523] を保持する属性についての適切な属性記述を掲げる <attributes> フィールドを含まなければならない(MUST)。さらに、<host> (例:, <ldap://ldap.example.com/cn=CA, dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>)を含む必要がある(SHOULD)。<host> を省略すること(例: <ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary>)は、「事前の知識が何であれ、そのクライアントは、適切なサーバに接続する必要がある可能性があること」に依存するという影響を与える。

5.3. CRL Entry 拡張 English

ISO/IEC、ITU-T および ANSI X9 for X.509 v2 CRL によって規定された CRL エントリ拡張は、追加的な属性を CRL エントリと関連づけるための手法を提供する [X.509] [X9.55]。X.509 v2 CRL フォーマットも、communities がそれらの communities に固有な情報を運ぶために、プライベート CRL エントリ拡張を定義できるようにする。CRL エントリ中の各拡張は、critical もしくは非-critical として設計される可能性がある。CRL が、そのアプリケーションが処理できない critical CRL エントリ拡張を含む場合、そのアプリケーションは、その CRL を、いかなる証明書の状態を判定するためにも使ってはならない(MUST NOT)。しかし、アプリケーションは、認識されない非-critical CRL エントリ拡張を無視する可能性がある。

下記の subsections は、インターネット CRL エントリ、および、情報について、標準的な場所において使われる推奨拡張を提供する。Communities は、追加的な CRL エントリ拡張を使うことを選択する可能性がある。; しかし、一般的な文脈において使われる可能性がある CRL におけるあらゆる critical CRL エントリ拡張を採用する際に留意する必要がある。

この仕様において定義された CRL エントリ拡張についてのサポートは、準拠する CRL 発行者およびアプリケーションにとってはオプションとしてである。しかし、CRL 発行者は、この情報が入手可能な限り、理由コード (5.3.1 節) および invalidity 日付(5.3.2 節) を含む必要がある(SHOULD)

5.3.1. 理由コード English

reasonCode は、証明書失効についての理由を識別する非-critical CRL エントリ拡張である。CRL 発行者には、CRL エントリ中に有意な理由コードを含めることが強く薦められる。;しかし、理由コード CRL エントリ拡張は、unspecified (0) reasonCode 値を使う代わりに存在しない必要がある(SHOULD)

removeFromCRL (8) reasonCode 値は、その証明書が期限切れ(expired)か、あるいは、hold から削除されたか、のいずれかであるので、delta CRL 中にのみ現れ、「ある証明書は、CRL から削除されるべきものであること」を示す可能性がある。他のすべての理由コードは、
any CRL 中に現れ、「規定された証明書は、失効されたと見なされる必要があること」を示す可能性がある。

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

   -- reasonCode ::= { CRLReason }

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
             -- value 7 is not used
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }
 

5.3.2. Invalidity 日付 English

invalidity 日付は、その日に「そのプライベート鍵は、侵害された」か、あるいは、その日に「その証明書は、無効になった」と知られているか、あるいは推察されている日付を提供する非-critical CRL エントリ拡張である。この日付は、その CRL エントリ中の失効日付より前である可能性がある。これは、その CA が、その失効を処理した日付である。失効が、ある CRL 中の CRL 発行者によって最初に投稿されたとき、その invalidity 日付は、以前の CRL の発行日付に先行する可能性があるが、その失効日付は、以前の CRL の発行日よりも先行してはいけない(SHOULD NOT)。この情報が入手可能な限り、CRL 発行者には、それを CRL ユーザと共有することが強く薦められる 。

このフィールドに含まれる GeneralizedTime の値は、Greenwich Mean Time (Zulu) で表現されなければならない(MUST)。そして、4.1.2.5.2 節に規定されているように定義され、解釈されなければならない(MUST)

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

InvalidityDate ::= GeneralizedTime

5.3.3. 証明書発行者 English

この CRL エントリ拡張は、indirect CRL 中のエントリと関連づけられる証明書の発行者、すなわち、その発行配布点拡張において、その indirectCRL 表示子集合をもつ CRL を識別する。存在するとき、その証明書発行者 CRL エントリ拡張は、その発行者フィールド、および/または、その CRL エントリと対応する証明書の発行者代替名拡張から、ひとつ、もしくは、複数の名前を含む。この拡張が indirect CRL 中の最初のエントリ上に無い場合、その証明書発行者は、その CRL 発行者にされる。indirect CRL 中の以降のエントリ上に、この拡張が無い場合、その主体についての証明書発行者は、それに先行するエントリについてのものと同一である。このフィールドは、下記のように規定される。:

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

CertificateIssuer ::= GeneralNames

準拠する CRL 発行者は、この CRL エントリに対応する証明書の 発行者フィールドからの DN を、この拡張中に含まなければならない(MUST)。この DN の符号化は、その証明書において使われた符号化と同一でなければならない(MUST)

CRL 発行者は、この拡張に critical として印をつけるなければならない(MUST)。なぜならば、この拡張を無視した実装は、CRL エントリを証明書宛に正しく帰着(attribute)できなかったからである。この仕様は、「実装が、この拡張を認識できること」を推奨する(RECOMMEND)
 


4 <- index -> 6