3 <- index -> 5


4.  証明書および証明書拡張のプロファイル English

この章は、相互運用可能性および再利用可能な PKI を促進する公開鍵証明書についてのプロファイルを提供する。この章は、X.509 v3 証明書フォーマットおよび [X.509] に規定されている標準証明書拡張に基づく。ISO/IEC および ITU-T の文書は、1997 年版の ASN.1 を使っている。:本書は 1988 年版の ASN.1 の構文を使っているが、その符号化された証明書および標準拡張は、同等のものである。この章は、インターネットコミュニティ用の PKI をサポートするために要求されたプライベート拡張も規定する。

証明書は、広範な相互運用可能性の目標や、より広範な運用的要件および保証要件を範囲とする広範なアプリケーションや環境に使われる可能性がある。本書の目的は、広範な相互運用可能性および制限された特別な目的の要件を要求する一般的なアプリケーション用に、共通の基本線(baseline)を確立することにある。特に、非公式なインターネット電子メール用、IPsec 用および WWW アプリケーション用の X.509 v3 証明書の利用をサポートすることが強調される。

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

X.509 v3 証明書 basic 構文は、下記のとおり。署名の計算について、署名されるデータは、ASN.1 DER(Distinguished Encoding Rules)[X.690] を使って符号化される。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 MUST be v2 or v3

        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST 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
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }

下記の項目は、インターネットにおいて利用する X.509 v3 証明書を記述する。

4.1.1. 証明書フィールド English

証明書は、 3 つの要求されるフィールドの SEQUENCE である。これらのフィールドは、以降の節において詳細に記述されている。

4.1.1.1. tbsCertificate English

このフィールドは、サブジェクトおよび 発行者の名前、そのサブジェクトと関連づけられた公開鍵、 有効期間および他の関連情報を含む。このフィールドは、4.1.2 節に詳細に記述されており、tbsCertificate は、通常、4.2 節に記述された拡張を含む。

4.1.1.2. signatureAlgorithm English

signatureAlgorithm フィールドは、その CA によって、この証明書に署名するために使われる暗号アルゴリズムについての識別子を含む。[RFC3279]、[RFC4055] および [RFC4491] のリストは、署名アルゴリズム をサポートしていたが、他の署名アルゴリズムも、サポートされる可能性がある(MAY)

アルゴリズム 識別子 は、下記の ASN.1 構造体によって規定される。:

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

このアルゴリズム識別子は、暗号アルゴリズムを識別するために使われる。OBJECT IDENTIFIER component は、(SHA-1 を伴う DSA のような)アルゴリズムを識別する。そのオプションとしてのパラメータフィールドの内容は、識別されるアルゴリズムに従って多様となる。

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

4.1.1.3. signatureValue English

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

この署名を生成することによって、CA は、tbsCertificate フィールド中の情報の有効性を認定する。特に、その CA は、その公開鍵とする素材と、その証明書のサブジェクトの結合(binding)を認定する。

4.1.2. TBSCertificate English

TBSCertificate は、その証明書のサブジェクト および、それを発行した CA に関する情報を含む。すべての TBSCertificate は、そのサブジェクトと発行者の名前、そのサブジェクトと関連づけられた公開鍵、有効期間、バージョン番号およびシリアル番号を含む。; オプションとしての固有の識別子フィールドを含むものがある可能性がある(MAY)。この節の残りは、これらのフィールドの syntax and semantics を記述する。TBSCertificate は、通常、拡張を含む。インターネット PKI 用の拡張は、4.2 節に記述されている。

4.1.2.1. バージョン English

このフィールドは、符号化された証明書のバージョンを記述する。拡張が使われるとき、このプロファイルにおいて期待されているように、バージョンは、3(値は、2)でなければならない(MUST)。拡張が無いが、UniqueIdentifier がある場合、そのバージョンは、2(値は 1)である必要がある(SHOULD)。; しかし、そのバージョンは、3 である可能性がある(MAY)。基本(basic)フィールドのみがある場合、そのバージョンは、1である必要がある(SHOULD)。(この値は、 デフォルト値であるので、その証明書から省略される。); しかし、そのバージョンは、2 もしくは 3 である可能性がある(MAY)

実装は、あらゆるバージョンの証明書を受け取ることに備える必要がある(SHOULD)。少なくとも、準拠実装は、v3 証明書を解釈しなければならない(MUST)

v2 証明書の生成は、このプロファイルに基づく実装によって期待されることはない。

4.1.2.2. シリアル番号 English

シリアル番号 は、CA によって各証明書宛に割り当てられた正の整数でなければならない(MUST)。これは、所与の CA によって発行される各証明書について固有でなければならない(MUST)。(すなわち、発行者名およびシリアル番号は、固有の証明書を識別する。)CA は、その serialNumber が非負の整数となるように強制しなければならない(MUST)

上記の一意性要件を所与とすると、シリアル番号は、long 整数 を含むことが期待される可能性がある。証明書ユーザは、20 オクテットまでの serialNumber の値を扱うことができなければならない(MUST)。準拠 CA は、20 octet より長い serialNumberの値を使ってはならない(MUST NOT)

注: 非準拠 CA は、負値もしくはゼロのシリアル番号をもつ証明書を発行する可能性がある。証明書ユーザは、このような証明書を優美に扱う用意をする必要がある(SHOULD)

4.1.2.3. 署名 English

このフィールドは、その CA によって、その証明書に署名するために使われるアルゴリズムについてのアルゴリズム識別子を含む。

このフィールドは、その sequence 証明書(4.1.1.2 節)中の署名アルゴリズムフィールドと同一のアルゴリズム識別子を含まなければならない(MUST)。この オプションとしての parameters フィールドの内容は、識別されるアルゴリズムに従って多様となる。[RFC3279]、[RFC4055] および [RFC4491] リストは、署名アルゴリズムをサポートしていたが、他の署名アルゴリズムも、サポートされる可能性がある(MAY)

4.1.2.4. 発行者 English

発行者フィールドは、証明書に署名して発行した主体を識別する。この発行者フィールドは、空でない DN(Distinguished Name)を含まなければならない(MUST)。この発行者フィールドは、X.501 type Name [X.501] として規定される。Name は、下記の ASN.1 構造体によって規定される。:

 
   Name ::= CHOICE { -- only one possibility for now --
     rdnSequence  RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET SIZE (1..MAX) 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 は、country 名や、US のように対応する値のような属性から成る階層的な 名前を記述する。そのコンポーネントである AttributeValue の種類は、AttributeType によって判定される。; 一般に、これは、DirectoryString となる。

DirectoryString type は、PrintableString, TeletexString, BMPString, UTF8String および UniversalString の選択として規定されている。このプロファイルに準拠する CA は、DirectoryString について PrintableString か、あるいは、UTF8String のいずれかによる符号化を、ふたつの例外と共に使わなければならない(MUST)。CA が以前に TeletexString、BMPString もしくは UniversalString を使って符号化された属性をもつ発行者フィールドをもつ証明書を発行したことがある場合、その CA は、下位互換性を確保するために、DirectoryString のこれらの符号化を使い続ける可能性がある(MAY)。また、既存の CA が、TeletexString, BMPString, もしくは UniversalString を使って符号化された属性を伴う発行者フィールドをもつ証明書を発行する場合、ドメインに追加された新しい CA は、既存の CA が使っている符号化と同一の符号化を使っている既存の CA と共有する属性を符号化する可能性がある(MAY)

上記のように、DN は、属性から成る。この仕様は、名前中に現れる可能性がある属性種別の集合を制限しない。 しかし、準拠実装は、下記に定義される属性種別の集合を含む発行者名をもつ証明書を受け取ることに備えなければならない(MUST)。この仕様は、追加的な属性種別についてのサポートを推奨する(RECOMMENDS)

属性の標準 sets は、X.500 シリーズの仕様 [X.520] に規定されている。 この仕様の実装は、発行者およびサブジェクト(4.1.2.6 節) の名前中の下記の standard 属性種別を受け取ることに備えなければならない(MUST)。:

さらに、この仕様の実装は、発行者およびサブジェクトの名前中の下記の標準属性種別を受け取ることに備える必要がある(SHOULD)。:

これらの属性種別についての構文および関連するオブジェクト識別子(OID)は、Appendix A 中の ASN.1 モジュールで提供される。

さらに、この仕様の実装は、[RFC4519] に定義されているように、domainComponent 属性を受信することに備えなければならない(MUST)。DNS(Domain Name System)は、階層的な資源へのラベルづけシステムを提供する。 この属性は、彼らの DNS 名と対応する DN を使うことを望む組織用に convenient メカニズムを提供する。これは、その代替名拡張の dNSName component を代替するものではない。実装には、そのような名前を DNS 名中に網羅することは、要求されない。この属性種別について、その syntax および関連する OID は、Appendix A 中の ASN.1 モジュールにおいて提供される。IDN を domainComponent 属性種別 との利用のために符号化するためのルールは、7.3 節に規定されている 。

証明書ユーザは、証明書パス検証(6 章)用に名前 chaining を行うため、発行者 DN およびサブジェクト DN(4.1.2.6節)フィールドを処理することに備えなければならない(MUST)。名前 chaining は、ある証明書中の 発行者 DN を CA 証明書中のサブジェクト名と突合することによって行われる。DN を比較するためのルールは、7.1節に規定されている。ある証明書中の発行者およびサブジェクトフィールド中の名前が 7.1節に規定されているルールに照らして一致する場合、その証明書は、自己発行される。

4.1.2.5. 有効性 English

証明書の有効期間は、その CA が、その証明書の状態についての情報を維持管理することを保証する期間である。このフィールドは、ふたつの日付の SEQUENCE として表現される。: 「その証明書の有効期間が始まる日付」および「その証明書の有効期間が終わる日付」。notBefore と notAfter の両方が、UTCTime もしくは GeneralizedTime として符号化される可能性がある。

このプロファイルに準拠する CA は、常に、証明書の有効期間を UTCTime として 2049 年まで、符号化しなければならない(MUST)。;2050 年以降の証明書の有効期日は、GeneralizedTime として符号化されなければならない(MUST)。準拠するアプリケーションは、UTCTime か、あるいは、GeneralizedTime のいずれかに符号化される validity 日付を処理できなければならない(MUST)

証明書についての有効期間は、notBefore から notAfter まで(inclusive)の期間である。

状況によっては、デバイスには、正常な失効日付を割り当てられることができなかった証明書が与えられることがある。例えば、あるデバイスは、そのモデルおよびシリアル番号を、その公開鍵に結合する証明書を発行される可能性がある。;このような証明書は、そのデバイスの lifetime 全期間に渡って使われることが意図されている。

「証明書は、well-defined expiration 日付をもたないこと」を示すために、その notAfter には、99991231235959Z の GeneralizedTime 値が割り当てられる必要がある(SHOULD)

その発行者が、状態情報を(notAfter 日付が 99991231235959Z であるときを含む) notAfter 日付まで維持管理できないとき、その発行者は、「妥当な証明書パスが、状態情報の維持管理が終了した後、その証明書について存在しないこと」を確認しなければならない(MUST)。これは、その証明書上の署名を検証するために使われる公開鍵を収め、trust anchor として、その証明書上の署名を検証するために使われる公開鍵の利用を広めている、すべての CA 証明書の期限切れもしくは失効によって達成される可能性がある。

4.1.2.5.1. UTCTime English

UTCTime(universal time type)は、日付および時刻の表現のために意図された標準 ASN.1 type である。UTCTime は、ふたつの low-order digit を通じて年を規定し、時刻は、1 分もしくは 1 秒の制度まで規定される。UTCTime は、Z (for Zulu もしくは Greenwich Mean Time) か、あるいは、時差(time differential)のいずれかを含む。

このプロファイルの目的には、UTCTime の値は、Greenwich Mean Time (Zulu) で表現されなければならない(MUST)。そして、たとえ秒の数がゼロである場合でも、秒を含まなければならない(MUST)。(すなわち、日時は、YYMMDDHHMMSSZ。)準拠システムは、下記のように、year フィールド (YY) を解釈しなければならない(MUST)。:

YY が 50 以上である場合、その年は、19YY と解釈されるものとする(SHALL)。また、

YY が 50 より小さい場合、その年は、20YY と解釈されるものとする(SHALL)

4.1.2.5.2. GeneralizedTime English

一般化された時刻 type である GeneralizedTime は、時刻の可変な精度表現についての標準 ASN.1 type である。オプションとして、GeneralizedTime フィールドは、ローカルと、グリニッジ標準時の間の時差の表現を含むことができる。

このプロファイルの目的のため、GeneralizedTime の値は、Greenwich Mean Time(Zulu)で表現されなければならない(MUST)。そして、たとえ秒の数がゼロの場合でも、秒を含んではならない(MUST)。(すなわち、時刻は、YYYYMMDDHHMMSSZ である。)GeneralizedTime の値は、fractional な秒を含んではならない(MUST NOT)

4.1.2.6.サブジェクト English

サブジェクトフィールドは、サブジェクト公開鍵フィールド中に保管される公開鍵と関連づけられた主体を識別する。そのサブジェクト名は、サブジェクト フィールド、かつ/または、subjectAltName 拡張内で運ばれる可能性がある(MAY)。そのサブジェクトが CA である(例: 4.2.1.9節において検討されているように、basic制約拡張が存在し、cA の値が TRUE である)場合、そのサブジェクトフィールドは、そのサブジェクト CA によって発行された、すべての証明書中の発行者フィールド (4.1.2.4 節)の内容と一致する非-empty DN と共に広告されなければならない(MUST)。そのサブジェクトが CRL 発行者である場合(例: 4.2.1.3 節において検討されたように、鍵用途拡張が存在し、cRLSign の値が TRUE である場合)、そのサブジェクトフィールドは、そのサブジェクト CRL 発行者によって発行された、すべての CRL 中の発行者フィールド (5.1.2.3 節)の内容と一致する非-empty DN と共に広告されなければならない(MUST)。サブジェクト命名情報が subjectAltName 拡張(例: 電子メールアドレスもしくは URI のみに該当する鍵)中にのみある場合、そのサブジェクト名は、空の文字列でなければならない(MUST)。そして、subjectAltName 拡張は、critical でなければならない(MUST)

これが空でない場合、そのサブジェクトフィールドは、X.500 DN を含まなければならない(MUST)。その DN は、発行者フィールドによって定義されたように、そのひとつの CA によって認定された各サブジェクト entity について、固有でなければならない(MUST)。CA は、同一のサブジェクト entity と同一の DN をもつ、ひとつより多い証明書を発行する可能性がある(MAY)

サブジェクトフィールドは、X.501 type Name として規定される。このフィールドについての実装要件は、発行者フィールド (4.1.2.4 節)について定義されたものである。この仕様の実装は、発行者フィールドについて要求された属性種別を収めるサブジェクト名を受信することに備えなければならない(MUST)。この仕様の実装は、発行者フィールドについて推奨された属性種別を収めるサブジェクト 名を受信することに備える必要がある(SHOULD)。これらの属性種別について、その構文および関連する オブジェクト識別子(OID)は、Appendix A 中の ASN.1 モジュールにおいて提供される。この仕様の実装は、普通ではない(unfamiliar)属性種別を処理するため(すなわち、名前を連鎖させるため)に、7.1 節中の比較ルールを使う可能性がある(MAY)。この属性値は、DirectoryString から符号化オプションのひとつを使うものである。バイナリ比較は、普通ではない属性種別が DirectoryString 中に見られるもの以外の符号化オプション以外の符号化オプションをもつ属性値を含むとき、使われる必要がある。これは、実装がそのサブジェクト名中に見慣れない属性をもつ証明書を処理できるようにする。

type DirectoryString の属性値を符号化するとき、準拠 CA は、下記の例外はあるが、PrintableString もしくは UTF8String の符号化を使わなければならない(MUST)。:

(a) その証明書のサブジェクトが CA であるとき、そのサブジェクトフィールドは、それがサブジェクト CA によって発行された、すべての証明書中の発行者フィールド(4.1.2.4 節)において符号化されているのと同じ方法で符号化されなければならない(MUST)。それゆえ、TeletexString、BMPString あるいは UniversalString encodings を使ってを発行する サブジェクト CA が証明書の発行者フィールド中の属性を符号化する場合、その CA 宛に発行された証明書のサブジェクトフィールドは、同一の符号化を使わなければならない(MUST)

(b) その証明書のサブジェクトが CRL 発行者であるとき、そのサブジェクトフィールドは、それがサブジェクト CRL 発行者によって発行された、すべての CRL 中の発行者フィールド(5.1.2.3 節)において符号化されているのと同じ方法で符号化されなければならない(MUST)

(c) TeletexString、BMPString および UniversalString は、下位互換性のために含められる。そして、新しいサブジェクトのための証明書用に使われてはいけない(SHOULD NOT)。しかし、これらの種別は、その名前が以前に確立されている証明書において使われる可能性がある(MAY)。これは、新しい証明書が既存のサブジェクト宛に発行されている場合、あるいは、符号化された属性が、他のサブジェクト宛に発行された証明書において以前から確立されている新しいサブジェクト宛に証明書が発行されている場合を含む。証明書ユーザは、これらの種別をもつ証明書を受信することに備える必要がある(SHOULD)

旧来の(legacy)実装が、存在しており、そこでは、電子メールアドレスは、サブジェクト DN が emailAddress 属性 [RFC2985] として埋め込まれる。emailAddress についての属性値は、'@' という文字の包含を許容するために type IA5String となっており、これは、PrintableString character set の一部ではない。emailAddress 属性値は、case-sensitive ではない。(例: "subscriber@example.com"は、"SUBSCRIBER@EXAMPLE.COM" と同一である。)

電子メールアドレスをもつ新しい証明書を生成する準拠実装は、このような identities を記述するために、サブジェクト代替名拡張 (4.2.1.6 節)中に rfc822Name を使わなければならない(MUST)。旧来の実装をサポートするために、同時に emailAddress 属性をもサブジェクト DN 中に含めることは、望ましくないが、許可されている。

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

このフィールドは、その公開鍵を運び、その鍵が使われるアルゴリズム(例: RSA、DSA もしくは Diffie-Hellman)を識別するために使われる。そのアルゴリズムは、4.1.1.2 節に規定されている AlgorithmIdentifier structure を使って識別される。その公開鍵の素材(公開鍵および parameters)を符号化するための supported アルゴリズム、および、その手法についてのオブジェクト識別子は、[RFC3279]、[RFC4055] および [RFC4491] に規定されている。

4.1.2.8. 固有な識別子 English

これらのフィールドは、 そのバージョンが 2 もしくは 3 (4.1.2.1 節)である場合にのみなければならない(MUST)。これらのフィールドは、そのバージョンが 1 である場合、なければならない(MUST NOT)。サブジェクトおよび 発行者の固有な識別子は、常に、サブジェクト、かつ/または、発行者名の再利用の可能性を扱うために、その証明書中にある。このプロファイルは、 「名前が異なる entities 用に再利用されないこと」を推奨し、「インターネット証明書は、固有な識別子を利活用しないこと」を推奨する。このプロファイルに準拠する CA は、固有の識別子をもつ証明書を生成してはならない(MUST NOT)。このプロファイルに準拠するアプリケーションは、固有の識別子を含む証明書を parsing できる必要がある(SHOULD)が、その固有の識別子に関する処理上の要件は、無い。

4.1.2.9. 拡張 English

このフィールドは、そのバージョンが 3(4.1.2.1 節)である場合にのみ、現れなければならない(MUST)。存在する場合、このフィールドは、ひとつ、もしくは、複数の証明書拡張の SEQUENCE である。インターネット PKI における証明書拡張のフォーマットおよび内容は、4.2 節に規定されている。

4.2. 証明書拡張 English

X.509 v3 証明書用に規定された拡張は、追加的な属性をユーザもしくは公開鍵と関連づけるための手法、および、CA 間の関係を管理するための手段を提供する。X.509 v3 証明書フォーマットは、コミュニティがそれらのコミュニティに固有な情報を運ぶためにプライベート拡張を定義できるようにもする。証明書中の各拡張は、critical か、あるいは、非-critical のいずれかとして指定されている。証明書を使うシステムは、それが解釈できない critical 拡張に遭遇した場合、あるいは、それが処理できない情報を収めた critical 拡張に遭遇した場合、その証明書を棄却しなければならない(MUST)。非-critical 拡張は、それが認識されない場合、無視される可能性がある(MAY)が、 それが解釈される場合、処理されなければならない(MUST)。下記の節は、インターネット証明書内で使われる推奨(recommended)拡張、および、情報についての標準の場所を提供する。コミュニティは、追加的な拡張を使うことを選択する可能性がある。; しかし、一般的な文脈における利用を妨げる可能性がある、あらゆる証明書中の critical 拡張を採用する際にも注意が払われるべきである。

各拡張は、ひとつの OID と、ひとつの ASN.1 構造体を含む。ある拡張が証明書中にあるとき、その OID は、フィールド extnID として現れ、対応する ASN.1 DER で符号化された structure は、octet string extnValue の値である。証明書は、ひとつより多くの特定の拡張を含まなければならない(MUST NOT)。例えば、証明書は、ひとつの authority 鍵識別子拡張(4.2.1.1 節)のみを含む可能性がある。ある拡張は、デフォルト値 FALSE を伴う critical の boolean を含む。各拡張についてのテキストは、このプロファイルに準拠する CA 用の critical フィールドについて、許容可能な値を規定する。

準拠 CA は、鍵識別子(4.2.1.1 節および 4.2.1.2 節)、基本制約(4.2.1.9 節)、鍵用途(4.2.1.3 節)および証明書ポリシー(4.2.1.4 節)拡張をサポートしなければならない(MUST)。その CA が、そのサブジェクトフィールドについて、空の sequence をもつ証明書を発行する場合、その CA は、サブジェクト 代替名拡張(4.2.1.6 節)をサポートしなければならない(MUST)。それ以外の拡張についてのサポートは、任意(OPTIONAL)である。準拠 CA は、この仕様内で識別されていない拡張をサポートする可能性がある(MAY)。; 証明書発行者には、「このような拡張に critical として印をつけることは、相互運用可能性を損なう可能性がある」と警告される。

少なくとも、このプロファイルに準拠するアプリケーションは、下記の拡張を認識しなければならない(MUST)。: 鍵用途(4.2.1.3 節)、証明書ポリシー(4.2.1.4 節)、サブジェクト代替名(4.2.1.6 節)、基本制約(4.2.1.9 節)、名前制約(4.2.1.10 節)、ポリシー制約(4.2.1.11 節)、拡張された鍵用途(4.2.1.12 節) および inhibit anyPolicy(4.2.1.14 節)。

さらに、このプロファイルに準拠する アプリケーションは、authority およびサブジェクトの鍵識別子(4.2.1.1 節および 4.2.1.2 節) および ポリシーマッピング (4.2.1.5 節) 拡張を認識する必要がある(SHOULD)

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. Authority 鍵識別子 English

authority 鍵識別子拡張は、証明書に署名するために使われるプライベート鍵に対応する公開鍵を識別するための手段を提供する。この拡張は、ある発行者が複数の署名鍵をもつ場合(複数の同時生成された鍵ペアに起因するか、あるいは、changeover に起因するかのいずれか)、使われる。その識別は、鍵識別子(発行者の証明書中のサブジェクト鍵識別子)か、あるいは、発行者名およびシリアル番号のいずれかに基づく可能性がある(MAY)

authorityKeyIdentifier 拡張の keyIdentifier フィールドは、証明書パスの構築を容易にするために、準拠 CA によって生成されたすべての証明書中に含まれなければならない(MUST)。ひとつの例外がある。; ある CA が、その公開鍵を「自己署名」証明書 の形態で配布する場合、その authority 鍵識別子は、省略される可能性がある(MAY)。自己署名された証明書上の署名は、その証明書のサブジェクト公開鍵と関連づけられるプライベート鍵と共に生成される。(これは、「その発行者は、公開鍵とプライベート鍵の両方を保持すること」を証明する。)この場合、そのサブジェクトと authority の鍵識別子は、一致するが、そのサブジェクト鍵識別子のみが、証明書パス構築のために必要とされる。

keyIdentifier フィールドの値は、その証明書の署名を検証するために使われる公開鍵、あるいは、固有の値を生成する手法から取得される必要がある(SHOULD)。鍵識別子をその公開鍵から生成するためのふたつの卑近な手法は、4.2.1.2 節に記述されている。鍵識別子が以前に確立されていない場合、この仕様は、keyIdentifiers を生成するために、あるいは、異なるハッシュアルゴリズムを使う同様の手法の利用のために、これらの手法のひとつを使用することを推奨する(RECOMMENDS)。鍵識別子が以前に確立している場合、その CA は、以前に確立された識別子を使う必要がある(SHOULD)

このプロファイルは、すべての証明書ユーザによる鍵識別子手法についてのサポートを推奨する(RECOMMENDS)

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

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 証明書になければならない(MUST)。basic制約拡張 (4.2.1.9 節) を含む、すべての証明書(すなわち cA という値をもつ、すべての証明書)は、TRUE である。準拠 CA 証明書において、その サブジェクト鍵識別子の値は、この証明書のサブジェクトによって発行された証明書の authority 鍵識別子拡張 (4.2.1.1 節)の鍵識別子フィールドにおかれた値でなければならない(MUST)。アプリケーションは、「鍵識別子が 証明書パス validation を行うとき、一致すること」を検証することを要しない。

CA 証明書について、サブジェクト鍵識別子は、その公開鍵から、あるいは、固有の値を生成する手法から引き出す必要がある(SHOULD)。その公開鍵から鍵識別子を生成するためのふたつの卑近な手法は、下記のとおり。:

(1) keyIdentifier は、(unused bit の tag、length および number を除く)BIT STRING subjectPublicKey という値の 160-bit SHA-1 hash から成る。

(2) keyIdentifier は、(unused bit の tag、length および number を除く)BIT STRING subjectPublicKey という値の SHA-1 hash の the least significant 60 bits によって転送された値として 0100 をもつ four-bit type フィールドから成る。

一意な番号を生成する他の手法も、適用可能である。

エンドエンティティ証明書について、そのサブジェクト鍵識別子拡張は、あるアプリケーションにおいて使われる特定の公開鍵を収める証明書を識別するための手段を提供する。end entity が複数の証明書を入手した場合(特に複数の CA から入手した場合)、その サブジェクト鍵識別子は、特定の公開鍵を収めている証明書の集合を機敏に識別するための手段を提供する。アプリケーションが適切な エンドエンティティ証明書を識別する際に支援するために、この拡張は、すべての エンドエンティティ証明書中に含まれる必要がある(SHOULD)

エンドエンティティ証明書について、サブジェクト鍵 識別子は、その公開鍵から取得される必要がある(SHOULD)。その公開鍵から鍵識別子を生成するための ふたつの卑近な手法は、上記のように識別された。

鍵識別子が以前に確立していない場合、この仕様は、keyIdentifiers を生成するために、これらの手法のひとつを利用すること、あるいは、異なるハッシュアルゴリズムを使う同様の手法の利用を推奨する(RECOMMENDS)。ある鍵識別子が以前に確立されている場合、その CA は、以前に確立された識別子を使う必要がある(SHOULD)

準拠 CA は、この拡張に、non-critical としてに印をつけなければならない(MUST)

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

SubjectKeyIdentifier ::= KeyIdentifier

4.2.1.3. 鍵用途 English

鍵用途拡張は、その証明書中に収められた鍵の目的(例: encipherment、署名、証明書署名)を規定する。その用途制約が、1 回より多くの操作に使える、ある鍵が制限されるべきとき、採用される可能性がある。例えば、ある RSA 鍵が公開鍵証明書および CRL 以外のオブジェクト上の署名を検証するためのみに使われる必要があるとき、その digitalSignature、かつ/または、nonRepudiation bits は、言明される。同様に、RSA 鍵が鍵管理用にのみ使われる必要があるとき、その keyEncipherment bit は、言明される。

準拠 CA は、 この拡張を他の公開鍵証明書もしくは CRL 上のディジタル署名を検証するために使われる公開鍵を含む証明書中に含まなければならない(MUST)。存在する場合、準拠 CA は、この拡張に critical と 印をつける必要がある(SHOULD)

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

KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1), -- recent editions of X.509 have
-- renamed this bit to contentCommitment
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }

KeyUsage type 中のビットは、下記のように使われる。:

digitalSignature bit は、そのサブジェクト公開鍵が証明書 (bit 5) および CRL (bit 6) 上の署名以外のディジタル署名(例: 主体認証サービス、データ発信元認証サービス、および/または、integrity サービスにおいて使われるもの)を検証するために使われるとき言明される。

nonRepudiation bit は、そのサブジェクト公開鍵が証明書上の署名(bit 5)と CRL 上の署名(bit 6)以外に、否認防止サービスを提供するために使われるディジタル署名を検証するために使われるとき、言明される。このサービスは、署名する主体が偽って何らかの行為を否認することから防護する。後日、争う場合、信頼できる第三者は、その署名されたデータの authenticity を判定する可能性がある。(「recent editions of X.509 は、nonRepudiation bit を contentCommitment に名前を変更したこと。」に注意。)

keyEncipherment bit は、そのサブジェクト公開鍵がプライベート鍵もしくは秘密鍵を暗号化するために(すなわち、鍵 transport 用に)使われるとき、言明される。例えば、この bit は、RSA 公開鍵が、対称 content-複合鍵もしくは非対称プライベート鍵を暗号化するために使われるべきとき、セットされるものとする。

dataEncipherment bit は、そのサブジェクト公開鍵が生のユーザデータを、中間の対象鍵の利用無しに直接、暗号化するために使われるとき、言明される。この bit の利用は、極めて異例であることに注意。; ほぼ、すべてのアプリケーションは、対称鍵を確立するために、鍵 transport もしくは鍵 agreement を使う。

keyAgreement bit は、そのサブジェクト公開鍵が鍵 agreement 用に使われるとき、言明される。例えば、Diffie-Hellman 鍵 が鍵管理用に使われているとき、この bit は、セットされる。

keyCertSign bit は、そのサブジェクト公開鍵が公開鍵証明書上の署名を検証するために使われるとき、言明される。keyCertSign bit が言明される場合、基本(basic)制約拡張(4.2.1.9節)中の cA bit も、言明されなければならない(MUST)

cRLSign bit は、そのサブジェクト公開鍵が CRL 上の署名を検証するために使われるとき、言明される(例: CRL、delta CRL もしくは ARL)。

encipherOnly bit の意味は、keyAgreement bit が無いとき、定義されていない。encipherOnly bit が言明され、かつ、その keyAgreement bit もセットされているとき、そのサブジェクト公開鍵は、鍵 agreement を行う際にデータを暗号化するためにのみ、使われる可能性がある。

decipherOnly bit の意味は、keyAgreement bit が存在しない状況において、定義されていない。この decipherOnly bit が言明され、かつ、keyAgreement bit も set されるとき、そのサブジェクト公開鍵は、鍵 agreement を行う際にデータを複合するためにのみ使われる可能性がある。

keyUsage 拡張がある場合、そのサブジェクトの公開鍵は、対応する keyCertSign bit もしくは cRLSign bit がセットされていない限り、証明書上の署名、もしくは、CRL を検証するために使われなければならない(MUST NOT)。そのサブジェクト 公開鍵が証明書、および/または、CRL 上の署名を検証するためにのみに使われるべき場合、digitalSignature および nonRepudiation bits は、セットされてはいけない(SHOULD NOT)。しかし、digitalSignature、かつ/または、nonRepudiation bit が、そのサブジェクト公開鍵が、他のオブジェクトと同様に、証明書、および/または、CRL 上の署名を検証するために使われるべき場合、keyCertSign かつ/または cRLSign bits に加えてセットされる可能性がある(MAY)

keyUsage 証明書拡張中の nonRepudiation bit を他のr keyUsage ビットと組み合わせることは、その証明書が使われる文脈に依存して、セキュリティ implications をもつ可能性がある。digitalSignature と、nonRepudiation bits の間の、さらなる検討は、具体的な証明書ポリシーにおいて提供される可能性がある。

このプロファイルは、keyUsage 拡張の instantiation 中にセットされる可能性がある bits の組み合わせを制限しない。しかし、特定のアルゴリズムについての keyUsage 拡張用の適切な値は、[RFC3279]、[RFC4055] および [RFC4491] に規定されている。その keyUsage 拡張が証明書中にあるとき、少なくとも、その bits のひとつは、1 にセットされなければならない(MUST)

4.2.1.4. 証明書ポリシー English

証明書ポリシー拡張は、ひとつ、もしくは、複数のポリシー情報 の項(terms )の sequence を含み、その各々は、OID(オブジェクト識別子)と オプションとしてのqualifier から成る。存在する可能性がある(MAY)オプションとしての qualifier には、そのポリシーの定義を変更することは期待されない。証明書ポリシー OID は、証明書ポリシー拡張において 1 回以上、現れなければならない(MUST NOT)

エンドエンティティ証明書において、これらのポリシー情報 terms は、その証明書が発行された際に基づいたポリシーと、その証明書が使われる目的を表示する可能性がある。CA 証明書において、これらのポリシー情報の項は、この証明書を含む証明書パスについてのポリシーの集合を制限する。ある CA が、この証明書を含む証明書パスについてのポリシーの集合を制限することを望まないとき、これは、{ 2 5 29 32 0 } の値をもつ anyPolicy という特別なポリシーを言明する可能性がある(MAY)

特定のポリシー要件をもつアプリケーションは、それらが受領するようなポリシーのリストをもち、その証明書中のポリシー OID をそのリストと比較することが期待される。この拡張が critical である場合、そのパス検証ソフトウェアは、この拡張(オプションとしての qualifier を含む)を解釈できなければならない(MUST)。あるいは、その証明書を棄却しなければならない(MUST)

相互運用可能性を促進するため、このプロファイルは、「ポリシー情報の項が、ひとつの OID のみから成ること」を推奨する(RECOMMEND)。ある OID が単独で不十分な場合、このプロファイルは、「qualifier の利用が、この節において識別されたものに制限されること」を強く推奨する。qualifier が特別なポリシー anyPolicy と共に使われるとき、それらは、この節において識別された qualifier に制限されなければならない(MUST)。パス検証の結果として返されるそれらの qualifier のみが、考慮される。

この仕様は、証明書ポリシーの著者および証明書発行者による利用のために、ふたつのポリシー qualifier 種別を規定する。その qualifier 種別は、CPS Pointer および User Notice qualifier である。

CPS Pointer qualifier は、その CA によって発行された CPS(Certification Practice Statement) 宛のポインタを含む。その pointer は、URI の形態をとる。この qualifier について、処理要件は、ローカルな問題である。この拡張について言明される重要性(criticality)の値に関わらず、この仕様によって、何の活動も強制されない。

ユーザ通知は、証明書が使われるとき、relying party 宛の表示が意図されている。パス検証の結果として返されたユーザ通知のみが、そのユーザに対する表示用に意図される。通知が重複している場合、ひとつのコピーのみが表示される必要がある。このような重複を防ぐため、この qualifier は、エンドエンティティ証明書中、および、他の組織宛に発行された CA 証明書中にのみ存在する必要がある(SHOULD)

そのユーザ notice は、ふたつの オプションとしてのフィールド(noticeRef フィールドおよび explicitText フィールド)をもつ。準拠 CA は、その noticeRef option を使ってはいけない(SHOULD NOT)

noticeRef フィールドは、使われる場合、ある組織を命名し、その組織によって広告された特定の textual statement を番号によって識別する。例えば、これは、その組織 "CertsRUs" および通知番号 1 を識別する可能性がある。典型的な実装において、そのアプリケーションソフトウェアは、現在の CertsRUs についての通知の集合を収める notice ファイルをもつ。; そのアプリケーションは、その notice text を、そのファイルから取り出し、それを表示する。メッセージは、ソフトウェアが、それ自体の環境用に特定の言語メッセージを選択できるようにしている多言語(multilingual)である可能性がある(MAY)

explicitText フィールドは、textual statement をその証明書中に直接、含む。explicitText フィールドは、最大 size として 200 characters をもつ string である。準拠 CA は、explicitText について、UTF8String encoding を使う必要がある(SHOULD)が、IA5String を使うことができる(MAY)。準拠 CA は、explicitText を VisibleString or BMPString として符号化しなければならない(MUST NOT)。explicitText string は、いかなる control characters (例: U+0000 to U+001F and U+007F to U+009F)も含んではいけない(SHOULD NOT)。UTF8String の符号化が使われているとき、すべての character sequences は、Unicode NFC(normalization form C)[NFC] に従って正規化される必要がある(SHOULD)

noticeRef と explicitText options の両方が、ひとつの qualifier 中に含まれる場合、かつ、そのアプリケーションソフトウェアが noticeRef option によって表示された notice text を配置できる場合、その text が、表示される必要がある(SHOULD) 。; さもなくば、その explicitText string が、表示される必要がある(SHOULD)

注: explicitText は、最大 size として 200 文字をもつが、非準拠 CA には、この制限を越えるものがある。それゆえ、証明書ユーザは、200 より多くの文字数をもつ explicitText を寛容に扱う必要がある(SHOULD)

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

   anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }

   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 for Internet policy qualifiers

   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 {
        ia5String        IA5String      (SIZE (1..200)),
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200)) }

4.2.1.5. ポリシーマッピング English

この拡張は、CA 証明書において使われる。これは、ひとつ、もしくは複数のペアの OID を掲げる。; 各ペアは、issuerDomainPolicy および subjectDomainPolicy を含む。その pairing は、「その issuing CA は、その issuerDomainPolicy をサブジェクト CA の subjectDomainPolicy と等価と見なすこと」を示す。

その issuing CA のユーザは、特定のアプリケーション用の issuerDomainPolicy を受容する可能性がある。ポリシーマッピングは、その issuerDomainPolicy と比較可能として受容される可能性があるサブジェクト CA に関するポリシーのリストを規定する。

ポリシーマッピング拡張において命名された各 issuerDomainPolicy は、また、同一の証明書中の証明書ポリシー拡張中に言明される必要がある(SHOULD)。ポリシーは、特別な値 anyPolicy (4.2.1.4 節)宛に/から、対応づけられなければならない(MUST NOT)

一般に、ポリシーマッピング拡張の issuerDomainPolicy フィールドに見られる証明書ポリシーは、 その証明書パス中の subsequent 証明書に含めるためには許容可能なポリシーと見なされていない。状況によっては、CA は、あるポリシー (p1) から別の (p2) 宛にマップすることを望むが、issuerDomainPolicy (p1) が以降の証明書に含まれることについて、受容可能と見なされるべきことを、なおも望む可能性がある。これは、例えば、その CA がポリシー p1 の利用からポリシー p2 の利用に切り替える処理中であり、かつ、そのポリシーの各々のもとで発行された有効な証明書をもつ場合、起きる可能性がある。CA は、これを、ふたつのポリシーマッピングを、それが発行する CA 証明書中に含めることによって示す可能性がある。各ポリシーマッピングは、p1 の issuerDomainPolicy をもつことになる。; 一方のポリシーマッピングは、p1 の subjectDomainPolicy をもつことになり、他方は、p2 の subjectDomainPolicy をもつ。

この拡張は、CA、および/または、アプリケーションによってサポートされる可能性がある(MAY)。準拠 CA は、 この拡張に critical として印をつける必要がある(SHOULD)

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

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

4.2.1.6. サブジェクト代替名 English

サブジェクト代替名拡張は、その証明書の サブジェクトに該当する identities を許容する。これらの identities は、その証明書のサブジェクトフィールド中の identity に加えて、あるいは、その代わりに含まれる可能性がある。Defined オプションは、インターネット電子メールアドレス、DNS 名、IP アドレスおよび URI(Uniform Resource Identifier)を含む。他のオプションが、completely ローカルな定義を含めて存在する。複数の名前形態、および複数の各名前形態の事例が含まれる可能性がある(MAY)。このような identities が証明書に該当する限り、そのサブジェクト代替名(もしくは発行者 代替名)拡張が、使われなければならない(MUST)。; しかし、DNS 名は、4.1.2.4節に記述されているように、domainComponent 属性を使って サブジェクトフィールド中に表現される可能性もある(MAY)。「このような名前がそのサブジェクトフィールド実装中に表現されている場合は、それらを DNS 名に変換することを要求されないこと」に注意。

サブジェクト代替名は、決定的に(definitively)その公開鍵に該当すると考えられるので、サブジェクト代替名のすべての parts は、その CA によって検証されなければならない(MUST)

さらに、その証明書中に含まれる唯一のサブジェクト identity が (例: 電子メールアドレス)からの代替名である場合、その サブジェクト DN は、空(an empty sequence)でなければならない(MUST)。そして、subjectAltName 拡張が、存在しなければならない(MUST)。そのサブジェクトフィールドが空の sequence を含む場合、その issuing CA は、 critical として印がつけられている subjectAltName 拡張を含まなければならない(MUST)。subjectAltName 拡張を、空でない サブジェクト DN をもつ証明書中に含むとき、準拠 CA は、subjectAltName 拡張に非-critical と印をつける必要がある(SHOULD)

subjectAltName 拡張がインターネットメールアドレスを含むとき、そのアドレスは、rfc822Name 中に保管されなければならない(MUST)。rfc822Name のフォーマットは、[RFC2821] の 4.1.2 節中に定義されているように "Mailbox" である。Mailbox は、"Local-part@Domain" という形態をもつ。「Mailbox は、(common name のような) phrase を、その前にもたないこと、その後にコメント(text surrounded in parentheses)をもたないこと、および、"<" and ">"によって囲まれないこと」に注意。国際化されたドメイン名を含むインターネットメールアドレスを符号化することについてのルールは、7.5 節において規定される。

subjectAltName 拡張が iPAddress を含むとき、そのアドレスは、[RFC791] に規定されているように、「ネットワーク byte 順」で、その octet string 中に保管されなければならない(MUST)。各 octet の LSB(least significant bit)は、そのネットワーク アドレス中の対応する byte の LSB である。IP v4 について、[RFC791] に規定されているように、その octet string は、ちょうど 4 octet を含まなければならない(MUST)。IP v6 について [RFC2460] に規定されているように、その octet string は、ちょうど 16 octet を含まなければならない(MUST)

subjectAltName 拡張が DNS label を収めるとき、ドメイン名は、dNSName (an IA5String)中に保管されなければならない(MUST)。その名前は、[RFC1034] の 3.5節によって規定され、[RFC1123] の 2.1 節によって変更されているように、"preferred name syntax" 中になくてはならない(MUST)。「大文字および小文字は、ドメイン名において認められているが、
to the case
付加されれる顕著さは無いこと」に注意。 さらに、その string " "は、法的なドメイン名であるが、" " という dNSName をもつ subjectAltName 拡張が、使われなければならない(MUST NOT)。最後に、インターネットメールアドレスについて、DNS 表記(subscriber.example.com instead of subscriber@example.com)の利用は、使われなければならない(MUST NOT)。; このような identities は、rfc822Name として符号化されるべきものである。国際化ドメイン名の符号化についてのルールは、7.2 節に規定されている。

subjectAltName 拡張が URI を含むとき、その名前は、uniformResourceIdentifier (an IA5String)中に保存されねばならない(MUST)。その名前は、 relative URI でなければならない(MUST NOT)。そして、それは、[RFC3986] 中に規定されている URI 構文 and 符号化 ルールに従わなければならない(MUST)。その名前は、 scheme (例: "http" or "ftp") と scheme-specific-part の両方を含まなければならない(MUST)。authority ([RFC3986], 3.2節)を含む URI は、全体が的確なドメイン名 もしくは、そのホストとして IP アドレスを含まなければならない(MUST)。IRI(Internationalized Resource Identifiers)を符号化することについてのルールは、7.4 節に規定されている。

[RFC3986] に規定されているように、scheme 名は、case-sensitive ではない(例: "http" is equivalent to "HTTP")。ホストの部分も(それがある場合)、case-sensitive ではないが、その scheme-specific-part の他の components は、case-sensitive である可能性がある。URI を比較するためのルールは、7.4節中に規定されている。

subjectAltName 拡張が directoryName 中に DN を含むとき、その符号化ルールは、4.1.2.4節において発行者フィールドについて規定されたものと同一である。その DN は、発行者フィールドによって定義されるように、ひとつの CA によって認定された各サブジェクト entity について一意でなければならない(MUST)。CA は、ひとつより多くの同一のサブジェクト entity に対して同一の DN をもつ証明書を発行する可能性がある(MAY)

この subjectAltName は、追加的な名前種別を otherName フィールドの利用を通じて運ぶ可能性がある(MAY)。その名前のフォーマットおよび semantics は、type-id フィールド中の OBJECT IDENTIFIER を通じて示される。その名前自体は、otherName 中の値フィールドとして運ばれる。例えば、Kerberos [RFC4120] フォーマット名は、otherName、Kerberos 5 principal 名 OID、および、Realm と PrincipalName の SEQUENCEに符号化される可能性がある。

サブジェクト代替名は、サブジェクト DN と同様の作法で、4.2.1.10節に記述されているように、名前制約拡張を使って制約される可能性がある(MAY)

subjectAltName 拡張が存在する場合、その sequence は、少なくとも、ひとつの エントリ を含まなければならない(MUST)。サブジェクトフィールドとは異なり、準拠 CA は、空の GeneralName フィールドを含む subjectAltNames を伴って証明書発行してはならない(MUST NOT)。例えば、rfc822Name は、IA5String として表現される。空の string は、valid IA5String であるが、このような rfc822Name は、このプロファイルによって許容されていない。証明書パスを処理するとき、このような証明書に遭遇するクライアントのふるまいは、このプロファイルによって定義されていない。

最後に、ワイルドカード文字(例: 名前の集合についての placeholder)を含む サブジェクト代替名の semantics は、この仕様によって対応されていない。特定の要件をもつアプリケーションは、このような名前を使う可能性がある(MAY)。しかし、それらは、その semantics を規定しなければならない(MUST)

   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.7. 発行者代替名 English

4.2.1.6節と同様に、この拡張は、Internet style 識別子を、その証明書発行者に関連づけるために使われる。発行者代替名は、4.2.1.6 節におけるように符号化されなければならない(MUST)。発行者代替名は、6 章中の証明書パス検証アルゴリズムの部分として処理されない。(すなわち、発行者 代替名は、名前 chaining において使われなく、名前制約は、強制されない。)

存在する場合、準拠 CA は、この拡張に非-critical と印をつける必要がある(SHOULD)

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

   IssuerAltName ::= GeneralNames

4.2.1.8. サブジェクトディレクトリ属性 English

サブジェクトディレクトリ属性拡張は、そのサブジェクトの identification 属性 (例: nationality)を運ぶために使われる。この拡張は、ひとつ、もしくは複数の属性の sequence として定義される。準拠 CA は、この拡張に非-critical として印をつけなければならない(MUST)

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

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

4.2.1.9. 基本制約 English

基本制約拡張は、「その証明書のサブジェクトが CA であるか否か?」および、この証明書を含む有効な証明書パスの最大 depth を識別する。

cA boolean は、「認定された公開鍵は、証明書署名を検証するために使われる可能性があるか否か?」を示す。この cA boolean が言明されていない場合、鍵用途拡張中の keyCertSign bit は、言明されなければならない(MUST NOT)。基本制約拡張が v3 証明書中に存在しないか、あるいは、その拡張は存在するが cA boolean が言明されていない場合、その certified 公開鍵は、証明書の署名を検証するために使われなければならない(MUST NOT)

pathLenConstraint フィールドは、その cA boolean が言明され、かつ、鍵用途拡張(があれば、それが)keyCertSign bit (4.2.1.3 節)を言明する場合のみ、有意である。この場合、これは、妥当な証明書パス中の、この証明書に従う可能性がある非自己発行中間証明書の最大数を与える。(注: その証明書パス中の最後の証明書は、中間証明書ではなく、この制限に含まれない。通常、最後の証明書は、エンドエンティティ証明書であるが、これは、CA 証明書である可能性がある。) ゼロの pathLenConstraint は、「妥当な証明書パスにおいて、従う非自己発行中間 CA 証明書は無い可能性があること」を示す。これが現れる場合、pathLenConstraint フィールドは、ゼロ以上でなければならない(MUST)。pathLenConstraint が現れない場合、制限は、提起されない。

準拠 CA は、証明書上のディジタル署名を検証するために使われる公開鍵を含むすべての CA 証明書中に、この拡張を含めなければならない(MUST)。そして、 このような証明書中の拡張に critical として印をつけなければならない(MUST)。この拡張は、証明書上のディジタル署名を検証する目的以外に排他的に使われる公開鍵を含む CA 証明書中の critical もしくは非-critical 拡張として登場する可能性がある(MAY)。このような CA 証明書には、CRL 上のディジタル署名を検証する目的以外に排他的に使われるもの公開鍵を含むもの、および、証明書 enrollment プロトコルと共に使われる鍵管理用の公開鍵を含むものが含まれる。この拡張は、エンドエンティティ 証明書中に critical もしくは、非-critical 拡張として存在する可能性がある(MAY)

CA は、cA boolean が言明され、その鍵用途拡張が keyCertSign bit を言明しない限り、pathLenConstraint フィールドを含んではならない(MUST NOT)

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

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

4.2.1.10. 名前制約 English

CA 証明書においてのみ使われなければならない(MUST)名前制約拡張は、名前空間を示すが、この中では、ある証明書パスにおいて以降の証明書中のすべてのサブジェクト名が配置されなければならない(MUST)。制限は、サブジェクト DN に適用され、サブジェクト代替名に適用される。制限は、規定された名前形態が存在するときのみ適用される。その種別の名前がその証明書中に無い場合、その証明書は、受容可能である。

名前制約は、(その証明書がパス中の最後の証明書でない限り)自己発行証明書には適用されない。(これは、名前制約を使う CA が鍵 rollover を実装するために自己発行証明書を採用することを防ぐ可能性がある。)

制約は、許可された名前 subtrees か、あるいは、排除される名前 subtrees か、の観点から規定されている。ある制約に合致する excludedSubtrees フィールド中のあらゆる名前は、permittedSubtrees 中に現れる情報に関わらず、妥当でない。準拠 CA は、この拡張に critical として印をつけなければならない(MUST)。そして、x400Address、ediPartyName もしくは registeredID の名前形態上の名前制約を提起してはいけない(SHOULD NOT)。準拠 CA は、名前制約が空の sequence である場合、証明書を発行しなければならない(MUST NOT)。すなわち、permittedSubtrees フィールドも、あるいは、excludedSubtrees のいずれも、存在してはならない(MUST)

このプロファイルに準拠するアプリケーションは、directoryName 名前形態に提起される名前制約を処理できなければならない(MUST)。そして、rfc822Name、uniformResourceIdentifier、dNSName および iPAddress 名前形態に提起される名前制約を処理できる必要がある(SHOULD)。critical として印がつけられた名前制約拡張が特定の名前形態上に制約を提起し、かつ、その名前 form の一例が、そのサブジェクトフィールド、もしくは、以降の証明書の subjectAltName 拡張中に現れる場合、そのアプリケーションは、その制約を処理するか、あるいは、その証明書を棄却するかのいずれかをしなければならない(MUST)

このプロファイル内で、最小のフィールドおよび最大のフィールドは、いかなる名前形態 とも共に使われない。それゆえ、最小値は、ゼロでなければならない(MUST)。そして、maximum は、存在してはならない(MUST)。しかし、あるアプリケーションが、以降の証明書中に現れる名前形態について、最小もしくは最大について、他の値を規定する critical 名前制約拡張に遭遇する場合、そのアプリケーションは、これらのフィールドを処理するか、あるいは、その証明書を棄却するか、のいずれかをしなければならない(MUST)

URI について、その制約は、その名前のホスト部分に適用される。この制約は、全体が適格とされるドメイン名として規定されなければならない(MUST)。そして、ホストもしくはドメインを規定する可能性がある(MAY)。例は、"host.example.com" や ".example.com" である。その制約が period で始まるとき、これは、ひとつ、もしくは、複数のラベルで拡張される可能性がある(MAY)。すなわち、".example.com" よいう制約は、host.example.com および my.host.example.com の両方によって満たされる。しかし、".example.com" という制約は、"example.com" によって満たされない。その制約が period で始まらないとき、これは、あるホストを規定する。ある制約が uniformResourceIdentifier 名前形態に適用され、かつ、以降の証明書が完全に適格なドメイン名として規定されたホスト名をもつ authority component を含まない uniformResourceIdentifier をもつ subjectAltName 拡張を含む場合(例: その URI が authority component を含まない場合、あるいは、その host 名が IP アドレスとして規定されている authority component を含む場合のいずれか)、そのアプリケーションは、その証明書を棄却しなければならない(MUST)

インターネットのメールアドレスについての名前制約は、特定の mailbox、特定のホストにあるすべてのアドレス、あるいは、 あるドメイン中のすべての mailboxes を規定する可能性がある(MAY)。特定の mailbox を示すために、その制約は、その complete メールアドレスである。例えば、"root@example.com" は、"example.com" というホスト上の root mailbox を示す。特定のホスト上のすべてのインターネットのメールアドレスを示すために、その制約は、そのホスト名として規定される。例えば、"example.com" という制約は、"example.com" というホストにある、いかなるメールアドレスによっても満たされる。あるドメイン内の、あらゆるアドレスを規定するために、その制約は、(URI と同様に) leading period と共に規定される。例えば、".example.com" は、"example.com"というドメイン中のすべてのインターネットメールアドレスを示すが、"example.com"というホスト上のインターネットのメールアドレスを示さない。

DNS 名前制限は、host.example.com として表明される。単純にゼロ、もしくは、より多くのラベルを、その名前の左側に追加することによって構築できる、あらゆる DNS 名は、その名前制約を満たす。例えば、www.host.example.com は、その制約を満たすが、host1.example.com は、満たさない。

Legacy な実装は、電子メールアドレスが type emailAddress(4.1.2.6 節)の、ある属性中のサブジェクト DN 中に埋め込まれている場合、存在する。rfc822Name 名前形態について、制約が提起されているが、その証明書がサブジェクト 代替名を含んでいないとき、rfc822Name 制約は、そのサブジェクト DN 中の type emailAddress の属性に適用されなければならない(MUST)。emailAddress および対応する OID についての ASN.1 構文は、Appendix A において提供される。

directoryName という形態の制約は、(その証明書が空でない サブジェクトフィールドを含むとき)その証明書中のサブジェクト フィールドに、また、subjectAltName 拡張中の type directoryName のあらゆる名前に適用されなければならない(MUST)。x400Address 形態の制限は、subjectAltName 拡張中の type x400Address の、あらゆる名前に適用されなければならない(MUST)

directoryName という形態の制限を適用するとき、実装は、DN 属性を比較しなければならない(MUST)。少なくとも、実装は、7.1節に規定されている DN 比較ルールに従わなければならない(MUST)。directoryName 形態の制限をもつ証明書を発行する CA は、ISO DN 名比較アルゴリズム全部の実装に依存してはいけない(SHOULD NOT)。これは、「名前制限は、サブジェクトフィールドもしくは subjectAltName 拡張において使われている符号化と同一となるように記述されなければならない(MUST)こと」を意味する。

iPAddress の構文は、(具体的には名前制約について)下記の追加と共に、4.2.1.6節に記述したようでなければならない(MUST)。IPv4 アドレスについて、GeneralName の iPAddress フィールドは、アドレス range [RFC4632] を表現するために、RFC 4632 (CIDR) の形式に符号化された eight (8) octets を含まなければならない(MUST)。IPv6 アドレスについて、その iPAddress フィールドは、同様に符号化された 32 octets を含まなければならない(MUST)。例えば、"class C" subnet 192.0.2.0 についての名前制約は、C0 00 02 00 FF FF FF 00 というオクテットのように、CIDR notation 192.0.2.0/24 (mask 255.255.255.0)を表現しながら表現される。

符号化および処理の名前制約についての追加的なルールは、7 章に規定されている。

otherName、ediPartyName および registeredID についての名前制約について、その構文および semantics は、この仕様によって規定されていないが、他の名前形態
用の名前制約についての構文および semantics は、他の文書に規定される可能性がある。

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.11. ポリシー制約 English

ポリシー制約拡張は、CA 宛に発行される証明書において使われる可能性がある。ポリシー制約拡張は、パス検証を 2 つの方法で制約する。これは、ポリシーマッピングを禁止するために使われる可能性、あるいは、「パス中の各証明書が許容可能なポリシー識別子を含むこと」を要求する可能性がある。

inhibitPolicyMapping フィールドがある場合、ポリシーマッピングの前に、そのパス中に現れる可能性がある追加的な証明書の数を示す値は、もはや許可されない。例えば、そのポリシーマッピングを示す 1 という値は、この証明書のサブジェクトによって発行された証明書では処理される可能性があるが、そのパス中の追加的な証明書では処理されない可能性がある。

requireExplicitPolicy フィールドがある場合、requireExplicitPolicy の値は、明示的なポリシーがそのパス全体について要求される前に、そのパス中に現れる可能性がある追加的な証明書の数を示す。explicit ポリシーが要求されるとき、そのパス中のすべての証明書が、その証明書ポリシー拡張中に受容可能なポリシー識別子を含むことが必要不可欠である。受容可能なポリシー識別子は、ポリシーマッピングを通じて等価であると宣言された証明書パス、もしくは、あるポリシーの識別子のユーザによって要求されるポリシーの識別子である。

準拠するアプリケーションは、requireExplicitPolicy フィールドを処理できなければならない(MUST)。そして、inhibitPolicyMapping フィールドを処理できる必要がある(SHOULD)。inhibitPolicyMapping フィールドをサポートするアプリケーションは、policyMappings 拡張についてのサポートも実装しなければならない(MUST)。policyConstraints 拡張が critical として印がつけられ、かつ、inhibitPolicyMapping フィールドがある場合、inhibitPolicyMapping フィールドについてのサポートを実装していないアプリケーションは、その証明書を棄却しなければならない(MUST)

準拠 CA は、ポリシー制約が空の sequence である場合、証明書を発行してはならない(MUST NOT)。すなわち、inhibitPolicyMapping フィールドか、あるいは、requireExplicitPolicy フィールドのいずれかが、存在しなければならない(MUST)。空のポリシー制約フィールド と出会うクライアントのふるまいは、このプロファイルにおいて対応されていない。

準拠 CA は、この拡張に critical と印をつけなければならない(MUST)

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.12. 拡張された鍵用途 English

この拡張は、鍵用途拡張中に示された基本的な目的に加えて/の代わりに、認定された公開鍵が使われる可能性がある、ひとつ、もしくは、複数の目的を示す。一般に、この拡張は、エンドエンティティ証明書中にのみ現れる。この拡張は、下記のように定義される。:

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

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

KeyPurposeId ::= OBJECT IDENTIFIER

鍵目的は、ニーズをもつ、あらゆる組織によって定義される可能性がある。鍵目的を識別するために使われるオブジェクト識別子は、IANA もしくは ITU-T 勧告 X.660 [X.660] に準拠して割り当てられなければならない(MUST)

この拡張(critical か、あるいは、非-critical のいずれか)は、証明書発行者のオプションにある可能性がある(MAY)

この拡張がある場合、その証明書は、示された目的のひとつにのみ使われなければならない(MUST)。複数の目的が示されている場合、そのアプリケーションは、(意図された目的が存在する限り)示されたすべての目的を解釈できる必要はない。証明書を使うアプリケーションは、「拡張された鍵用途拡張が、存在すること」および「特定の目的が、その証明書について、そのアプリケーションが許容可能となるように示されていること」を要求する可能性がある(MAY)

CA が、このようなアプリケーションを満足させるために拡大された鍵用途を含むが、その鍵の用途を制限することを望まない場合、その CA は、そのアプリケーションによって要求される特別な KeyPurposeId anyExtendedKeyUsage をその特定の鍵の目的に加えて含む可能性がある。準拠 CA は、この拡張に anyExtendedKeyUsage KeyPurposeId が存在する場合、critical と印をつけてはいけない(SHOULD NOT)。特定目的の存在を要求するアプリケーションは、anyExtendedKeyUsage OID を含むが、そのアプリケーションに期待される特定の OIDではないものを含む証明書を棄却する可能性がある(MAY)

ある証明書が 鍵用途拡張と拡張された鍵用途拡張の両方を含む場合、両拡張は、独立して処理されなければならない(MUST)。そして、その証明書は、両拡張と整合する目的にのみ、使われなければならない(MUST)。両拡張に整合する目的が無い場合、その証明書は、いかなる目的用にも使われてはならない(MUST NOT)

下記の鍵用途の目的が、規定されている。:

anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

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

id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW サーバ認証
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement

id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement

id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature

id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-- Email protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)

id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation

id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
-- Signing OCSP responses
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation

4.2.1.13. CRL 配布点 English

CRL 配布点拡張は、「どのように CRL 情報が取得されるか?」を識別する。この拡張は、非-critical である必要がある(SHOULD)が、このプロファイルは、CA およびアプリケーションによる、この拡張についてのサポートを推奨する(RECOMMENDS)。CRL 管理についての、さらなる検討は、5 章に含まれている 。

cRLDistributionPoints 拡張は、DistributionPoint の SEQUENCEである。DistributionPoint は、3 つのフィールド(distributionPoint、reasons および cRLIssuer)から成り、各フィールドは、オプションとしてのものである。これらのフィールドの各々は、オプションとしてのものであるが、DistributionPoint は、理由フィールドのみから成らなければならない(MUST NOT)。; distributionPoint か、あるいは、cRLIssuer のいずれかが存在しなければならない(MUST)。その証明書の発行者が、その CRL 発行者ではない場合、その cRLIssuer フィールドが存在し、かつ、その CRL 発行者の名前が含まなければならない(MUST)。その証明書 発行者 がその CRL 発行者でもある場合、準拠 CA は、cRLIssuer フィールドを省略しなければならない(MUST)。そして、distributionPoint フィールドを含まなければならない(MUST)

distributionPoint フィールドが存在するとき、これは、一般的な名前の SEQUENCE か、あるいは、単一の値 nameRelativeToCRLIssuer のいずれかを含む。DistributionPointName が複数の値を含む場合、各名前は、同一の CRL を取得するための異なるメカニズムを記述する。例えば、同一の CRL は、取得するために
LDAP と HTTP の両方を通じて利用可能である可能性がある。

distributionPoint フィールドが directoryName を含む場合、その directoryName についてのエントリは、関連づけられた理由についての現在の CRL を含み、その CRL は、関連づけられた cRLIssuer によって発行される。その CRL は、certificateRevocationList か、あるいは、authorityRevocationList 属性のいずれかの中に保管される可能性がある。その CRL は、ディレクトリ サーバがどのようにローカルで設定されていようとも、そこから、そのアプリケーションによって取得されるべきものである。そのアプリケーションが そのディレクトリ (例: DAP もしくは LDAP) にアクセスするために使うプロトコルは、ローカルな問題である。

DistributionPointName が type URI の一般的な名前を含む場合、下記の semantics が想定されなければならない(MUST)。: その URI は、関連づけられた理由について、現在の CRL への pointer であり、関連づけられる cRLIssuer によって発行される。HTTP もしくは FTP の URI scheme が使われるとき、その URI は、[RFC2585] に規定されているように、単一の DER で符号化された CRL を指さなければならない(MUST)。その URI 経由でアクセスされる HTTP サーバ実装は、media type application/pkix-crl を、その response の content-type ヘッダフィールド中に規定する必要がある(SHOULD)。LDAP の URI スキーム [RFC4516] が使われるとき、その URI は、その CRL を保持するエントリの DN を収めている<dn> フィールドを含まなければならない(MUST)。また、その CRL を保持する属性 [RFC4523] について、適切な属性記述を収める単一の <attrdesc> を含まなければならない(MUST)。さらに、<host> (例: <ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?certificateRevocationList;binary>)を含む必要がある(SHOULD)。<host> (例: <ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary>)を省略することは、「事前の知識が何であれ、そのクライアントは、適切なサーバに接続する必要がある可能性があること」に依存する、という影響を与える。存在するとき、DistributionPointName は、少なくとも、ひとつの LDAP もしくは HTTP の URI を含む必要がある(SHOULD)

その DistributionPointName が単一の値 nameRelativeToCRLIssuer を含む場合、その値は、DN fragment を提供する。この fragment は、その distribution point 名を取得するために CRL 発行者の X.500 DN に追加される。その DistributionPoint 中に cRLIssuer フィールドがある場合、その名前 fragment は、それが含む DN に追加される 。; さもなくば、その名前 fragment は、証明書発行者 DN に追加される。準拠 CA は、nameRelativeToCRLIssuer を配布点名を規定するために使ってはいけない(SHOULD NOT)。その DistributionPointName は、cRLIssuer が、ひとつ以上の DN を含むとき、nameRelativeToCRLIssuer alternative を使ってはならない(MUST NOT)

DistributionPoint が理由フィールドを無視する場合、その CRL は、すべての理由について失効情報を含まなければならない(MUST)。このプロファイルは、理由コードによる CRL の分割は、しないことを推奨する(RECOMMENDS)。準拠 CA が証明書中に cRLDistributionPoints 拡張を含むとき、それは、少なくとも、すべての理由について、その証明書を対象範囲とする CRL を指すひとつの DistributionPoint を含まなければならない(MUST)

cRLIssuer は、CRLに署名し、発行する主体を識別する。cRLIssuer がある場合、これは、その DistributionPoint が指している CRL の発行者フィールドからの DN のみを含まなければならない(MUST)。cRLIssuer フィールド中の名前の符号化は、その CRL の発行者フィールド中の符号化と、厳密に同一でなければならない(MUST)。その cRLIssuer フィールドが含まれており、かつ、そのフィールド中の DN が CRL が配置される X.500 もしくは LDAP ディレクトリエントリに対応しない場合、準拠 CA は、その distributionPoint フィールドを含まなければならない(MUST)

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

CRLDistributionPoints ::= 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),
privilegeWithdrawn (7),
aACompromise (8) }

4.2.1.14. Inhibit anyPolicy English

inhibit anyPolicy 拡張は、CA 宛に発行された証明書において使える。この inhibit anyPolicy 拡張は、それが中間の自己発行された CA 証明書中に現れるときを除いて、「 { 2 5 29 32 0 } という値を伴う特別な anyPolicy OID は、他の証明書ポリシーとの明示的な一致と見なされないこと」を示す。その値は、そのパス中に anyPolicy がもはや許可されなくなる前に現れる可能性がある追加的な非自己発行証明書の数を示す。例えば、1 という値は、「anyPolicy は、この証明書のサブジェクトによって発行された証明書において処理される可能性があるが、そのパス中の追加的な証明書においては処理されないこと」を示す。

準拠 CA は、この拡張に critical と印を付けなければならない(MUST)

id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }

InhibitAnyPolicy ::= SkipCerts

SkipCerts ::= INTEGER (0..MAX)

4.2.1.15. Freshest CRL (a.k.a。Delta CRL Distribution Point) English

freshest CRL 拡張は、「どのように delta CRL 情報は、取得されるか?」を規定する。この拡張は、準拠 CA によって、非-critical として印をつけられなければならない(MUST)。CRL 管理についてのさらなる検討は、5 章中に含まれている。

同様の構文は、この拡張および cRLDistributionPoints 拡張用に使われ、4.2.1.13節中に記述されている。同様の conventions は、両拡張に適用される。

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

FreshestCRL ::= CRLDistributionPoints

4.2.2. プライベートインターネット拡張 English

この節では、インターネット PKI における利用のために、ふたつの拡張を規定する。これらの拡張は、アプリケーションに、その発行者もしくはサブジェクトについてのオンライン情報を指図するために使われる可能性がある。各拡張は、アクセス手法およびアクセス場所の sequence を含む。そのアクセス手法は、入手可能な情報の種別を示すオブジェクト識別子である。そのアクセス場所は、その情報の場所とフォーマット、および、その情報を取得するための手法を黙示的にを規定する GeneralName である。

オブジェクト識別子は、その プライベート 拡張について規定される。その プライベート拡張に関連づけられる オブジェクト識別子は、arc 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. Authority 情報アクセス English

authority 情報アクセス拡張は、「この拡張が現れる証明書の発行者についての情報およびサービスに、どのようにアクセスするか?」を示す。情報およびサービスは、オンライン検証サービスおよび CA ポリシーデータを含む可能性がある。(CRL の場所は、この拡張において規定されない。;その情報は、cRLDistributionPoints 拡張によって提供される。)この拡張は、エンドエンティティ証明書もしくは CA 証明書中に含まれる可能性がある。 準拠 CA は、この拡張に非-critical として印をつけなければならない(MUST)

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 }

id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

文字列 AuthorityInfoAccessSyntax 中の各エントリは、この拡張が現れる証明書の発行者によって提供される追加的情報のフォーマット および場所を記述する。その情報の type およびフォーマットは、accessMethod フィールドによって規定される。; accessLocation フィールドは、その情報の場所を規定する。その取得メカニズムは、accessMethod によって意味される可能性、あるいは、accessLocation によって規定される可能性がある。

このプロファイルは、ふたつの accessMethod OID( id-ad-caIssuers および id-ad-ocsp)を規定する。

ある公開鍵証明書において、その id-ad-caIssuers OID は、追加的な情報が、この拡張を含む証明書を発行した CA 宛に発行された証明書を掲げるとき、使われる。参照される CA 発行者 description は、証明書ユーザを 、その証明書ユーザによって信頼される点において終端する証明書パスの選択の際に救うことが意図されている。

id-ad-caIssuers が accessMethod として現れるとき、その accessLocation フィールドは、参照される description サーバ、および、参照される description を取得するために、アクセスプロトコルを記述する。accessLocation フィールドは、GeneralName として規定され、これは、いくつかの形態をとる可能性がある。

accessLocation が directoryName であるとき、その情報は、どのようなディレクトリサーバがローカルで設定されていようとも、そこから、そのアプリケーションによって取得されるべきものである。directoryName についてのエントリは、[RFC4523] に規定されているように、crossCertificatePair、および/または、cACertificate 属性の中の CA 証明書を含む。そのアプリケーションが、そのディレクトリにアクセスするために使うプロトコル (例: 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>)は、事前の知識が何であろうと、「そのクライアントが、適切なサーバに接続する必要がある可能性があることに依存する」という影響を与える。

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

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

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

他の id-ad-caIssuers accessLocation 名前形態の意味論は、規定されない。

authorityInfoAccess 拡張は、id-ad-caIssuers accessMethod の複数の事例を含む可能性がある。その異なる例としては、同一情報にアクセスするために、異なる手法を規定する可能性、あるいは、異なる情報を指す可能性がある。id-ad-caIssuers accessMethod が使われるとき、少なくとも、一例は、HTTP [RFC2616] もしくは LDAP [RFC4516] の URI である accessLocation を規定する必要がある(SHOULD)

id-ad-ocsp OID は、この拡張を含んでいる証明書についての失効情報が OCSP(Online Certificate Status Protocol)[RFC2560] を使って入手可能なとき、使われる。

id-ad-ocsp が accessMethod として現れるとき、その accessLocation フィールドは、[RFC2560] に定義されている conventions を使っている OCSP responder の場所である。

追加的なアクセス記述子が他の PKIX 仕様において定義される可能性がある。

4.2.2.2. サブジェクト情報アクセス English

サブジェクト情報アクセス拡張は、「どのように、拡張が現れる証明書のサブジェクトのための情報およびサービスにアクセスするか?」を示す。そのサブジェクトが CA であるとき、情報およびサービスは、証明書検証サービスおよび CA ポリシーデータを含む可能性がある。そのサブジェクトが end entity であるとき、その情報は、提供されるサービスの種類、および、「どのように、それらにアクセスするか?」を記述する。この場合、この拡張の内容は、サポートされるサービスについてのプロトコル仕様中に定義されている。この拡張は、エンドエンティティ証明書もしくは CA の証明書中に含まれる可能性がある。準拠 CA は、この拡張に 非-critical として印をつけなければならない(MUST)

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }

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

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

sequence SubjectInfoAccessSyntax において、各エントリは、そのフォーマットおよび、この拡張が現れる証明書の subject によって提供される追加的情報の場所を記述する。その情報の type and フォーマットは、accessMethod フィールドによって規定されている。;accessLocation フィールドは、この情報の場所を規定する。その取得メカニズムは、accessMethod によって意味される可能性、あるいは、accessLocation によって規定される可能性がある。

このプロファイルは、そのサブジェクトが CA であるとき、使われるべき、ひとつのアクセス手法、および、 そのサブジェクトが end entity であるとき、使われるべき、ひとつのアクセス手法を規定する。追加的なアクセス手法が、将来、他のサービス用に、そのプロトコル仕様中に規定される可能性がある。

この id-ad-caRepository OID は、そのサブジェクトがリポジトリ中に証明書を発行する CA であるとき、使われる。その accessLocation フィールドは、いくつかの形態をとる可能性がある GeneralName として規定される。

その accessLocation が directoryName であるとき、どのようのディレクトリサーバがローカルで設定されていようとも、そこから、その情報は、そのアプリケーションによって取得されるべきものである。その拡張が CA 証明書を指すために使われるとき、その directoryName についてのエントリは、CA 証明書を [RFC4523] に規定されているように crossCertificatePair and/or cACertificate 属性中に含む。そのアプリケーションが、そのディレクトリにアクセスするために使うプロトコル(例: 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>)は、事前の知識が何であろうとも、「そのクライアントは、適切なサーバに接続する必要がある可能性があることに依存する」という影響を与える。

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

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

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

他の id-ad-caRepository accessLocation 名前形態 の semantics は、規定されていない。

subjectInfoAccess 拡張は、id-ad-caRepository accessMethod の複数の事例を含む可能性がある。異なる事例は、同一の情報にアクセスするための異なる手法を規定するか、あるいは、異なる情報を指す可能性がある。id-ad-caRepository accessMethod が使われるとき、少なくとも、一例は、HTTP [RFC2616] もしくは LDAP [RFC4516] URI である accessLocation を規定する必要がある(SHOULD)

この id-ad-timeStamping OID は、そのサブジェクトが [RFC3161] に規定されているTime Stamp プロトコルを使って timestamping サービスを提供するとき、使われる。その timestamping サービスが HTTP もしくは FTP 経由で利用可能である場合、accessLocation は、uniformResourceIdentifier でなければならない(MUST)。その timestamping サービスが電子メール経由で利用可能な場合、accessLocation は、rfc822Name でなければならない(MUST)。timestamping サービスが TCP/IP を使って利用可能な場合、dNSName もしくは iPAddress 名前形態 が使われる可能性がある。(accessMethod が id-ad-timeStamping であるとき)accessLocation の他の名前形態 の semantics は、この仕様によって規定されていない。

追加的な アクセス descriptor が、他の PKIX 仕様において規定されている可能性がある。

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

id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }

id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }


3 <- index -> 5