Certificate

証明書

証明書と証明書失効リスト (CRL) Profile という形でいくつかの標準のProfileがある

主なものがRFC 5280 Internet X.509 公開鍵機関のProfile

RFC 3279 アルゴリズムと識別子 for the Internet X.509 公開鍵基盤 証明書と証明書失効リスト (CRL) Profile

RFC 4055 インターネット X.509 公開鍵インフラストラクチャ証明書および証明書失効リスト (CRL) プロファイルで使用する RSA 暗号化の追加アルゴリズムと識別子

RFC 4491

RFC 5480 楕円曲線暗号主題公開鍵情報

RFC 8813 楕円曲線暗号主題公開鍵情報の説明

RFC 5758 DSAとECDSAの追加アルゴリズムと識別子

SHA2版DSA, ECDSA

RFC 6818 Profileの更新

RFC 3647 ポリシー

X.509v1では階層などが決められていたがv3ではExtensionで属性等を設定する

別Profile

商用国家安全保障アルゴリズム (CNSA) スイート証明書および証明書失効リスト (CRL) プロファイル

Suite Bは廃止

ECDSA P-256 または P-384 のみ

あるごりずむ

table:あるごりずむ

アルゴリズム OBJECT IDENTIFIER RFC

sha1 1.3.14.3.2.26 4055

sha224 2.16.840.1.101.3.4.2.4 4055,5758

sha256 2.16.840.1.101.3.4.2.1 4055,5758

sha384 2.16.840.1.101.3.4.2.2 4055,5758

sha512 2.16.840.1.101.3.4.2.3 4055,5758

dsa-with-sha224 2.16.840.1.101.3.4.3.1 5758

dsa-with-sha256 2.16.840.1.101.3.4.3.2 5758

ecdsa-with-sha224 1.2.840.10045.4.3.1 5758

ecdsa-with-sha256 1.2.840.10045.4.3.2 5758

ecdsa-with-sha384 1.2.840.10045.4.3.3 5758

ecdsa-with-sha512 1.2.840.10045.4.3.4 5758

table:RSASSA 組み合わせ?

AlgorithmIdentifier parameter RFC

mgf1 sha1 4055

mgf1 sha224 4055

mgf1 sha256 4055

mgf1 sha384 4055

mgf1 sha512 4055

rfc 5280

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

証明書は、幅広い相互運用性の目標と、より広範な運用および保証要件をカバーする、幅広いアプリケーションおよび環境で使用できます。本文書の目的は、幅広い相互運用性と限定的な特殊用途の要件を必要とする一般的なアプリケーションのための共通のベースラインを確立することです。特に、非公式なインターネット電子メール、IPsec、およびWWWアプリケーションにおけるX.509 v3証明書の使用をサポートすることに重点を置きます。

4.1. 基本的な証明書フィールド Basic Certificate Fields

code:Certificate

Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING }

TBSCertificate ::= SEQUENCE {

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

-- IF present, version MUST be v2 or v3

-- IF present, version MUST be v2 or v3

-- 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

-- extnIDで識別される拡張タイプに対応するASN.1値の

-- DERエンコーディングが含まれます

}

以下の項目では、インターネットで使用するための X.509 v3 証明書について説明します。

4.1.1. 証明書のフィールド

証明書は、3つの必須フィールドのシーケンスです。各フィールドについては、以下のサブセクションで詳しく説明します。

4.1.1.1. tbsCertificate

このフィールドには、サブジェクト名と発行者名、サブジェクトに関連付けられた公開鍵、有効期間、その他の関連情報が含まれます。これらのフィールドの詳細については、セクション4.1.2を参照してください。tbsCertificateには通常、セクション4.2で説明する拡張機能が含まれます。

4.1.1.2. signatureAlgorithm

signatureAlgorithm フィールドには、CA がこの証明書に署名するために使用する暗号アルゴリズムの識別子が含まれます。

アルゴリズム識別子は、以下の ASN.1 構造で定義されます。

code:AlgorithmIdentifier

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL }

アルゴリズム識別子は、暗号アルゴリズムを識別するために使用されます。OBJECT IDENTIFIER コンポーネントは、アルゴリズム（SHA-1 を使用した DSA など）を識別します。オプションのパラメータフィールドの内容は、識別されるアルゴリズムによって異なります。

このフィールドには、シーケンス tbsCertificate の署名フィールドと同じアルゴリズム識別子が含まれていなければなりません（セクション 4.1.2.3）。

4.1.1.3. signatureValue

この署名を生成することにより、CAはtbsCertificateフィールドの情報の有効性を証明します。特に、CAは公開鍵マテリアルと証明書のサブジェクト間の結びつきを証明します。

4.1.2. TBSCertificate

TBSCertificateシーケンスには、証明書のサブジェクトと発行元CAに関する情報が含まれます。すべてのTBSCertificateには、サブジェクト名と発行者名、サブジェクトに関連付けられた公開鍵、有効期間、バージョン番号、シリアル番号が含まれます。一部のTBSCertificateには、オプションで一意の識別子フィールドが含まれる場合があります。このセクションの残りの部分では、これらのフィールドの構文と意味について説明します。TBSCertificateには通常、拡張機能が含まれます。インターネットPKIの拡張機能については、セクション4.2で説明します。

4.1.2.1. Version

このフィールドは、エンコードされた証明書のバージョンを示します。本プロファイルで想定されているように、拡張機能が使用される場合、バージョンは3（値は2）でなければなりません（MUST）。拡張機能が存在しないが、UniqueIdentifierが存在する場合、バージョンは2（値は1）であるべきです（SHOULD）。ただし、バージョンは3であっても構いません（MAY）。基本フィールドのみが存在する場合、バージョンは1（デフォルト値として証明書から省略されます）であるべきです（SHOULD）。ただし、バージョンは2または3であっても構いません（MAY）。

実装は、あらゆるバージョンの証明書を受け入れる準備をすべきです（SHOULD）。

少なくとも、準拠する実装はバージョン3の証明書を認識しなければなりません（MUST）。

本プロファイルに基づく実装では、バージョン2の証明書の生成は想定されていません。

4.1.2.2. シリアル番号 Serial Number

シリアル番号は、CA が各証明書に割り当てる正の整数でなければなりません。シリアル番号は、特定の CA が発行する証明書ごとに一意でなければなりません（つまり、発行者名とシリアル番号によって証明書が一意に識別されます）。CA は、シリアル番号を非負の整数にする必要があります。

上記の一意性要件を考慮すると、シリアル番号には長整数(long integers)が含まれることが想定されます。証明書利用者は、最大 20 オクテットのシリアル番号値に対応できなければなりません。準拠 CA は、20 オクテットを超えるシリアル番号値を使用してはなりません（MUST NOT）。

注：非準拠 CA は、負またはゼロのシリアル番号を持つ証明書を発行する場合があります。証明書利用者は、そのような証明書を適切に処理できるように準備しておく必要があります。

4.1.2.3. 署名 Signature

このフィールドには、CAが証明書の署名に使用したアルゴリズムのアルゴリズム識別子が含まれます。

4.1.2.4. 発行者 Issuer

code:Name

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 は、国名などの属性とそれに対応する値（US など）で構成される階層的な名前を表します。構成要素 AttributeValue の型は AttributeType によって決定され、通常は DirectoryString になります。

DirectoryString 型は、PrintableString、TeletexString、BMPString、UTF8String、UniversalString のいずれかとして定義されます。このプロファイルに準拠する CA は、DirectoryString のエンコードとして PrintableString または UTF8String のいずれかを使用する必要があります（MUST）。ただし、2 つの例外があります。CA が以前に、TeletexString、BMPString、または UniversalString を使用してエンコードされた属性を持つ発行者フィールドを持つ証明書を発行している場合、CA は下位互換性を維持するために、これらのエンコードを DirectoryString として引き続き使用しても構いません（MAY）。また、既存の CA が TeletexString、BMPString、または UniversalString を使用してエンコードされた属性を持つ発行者フィールドを持つ証明書を発行しているドメインに、新しい CA を追加する場合は、既存の CA が使用するのと同じエンコードを使用して、既存の CA と共有する属性をエンコードしても構いません（MAY）。

前述のように、識別名は属性で構成されます。本仕様は、名前に出現し得る属性タイプのセットを制限しません。ただし、準拠する実装は、以下に定義される属性タイプのセットを含む発行者名を持つ証明書を受信できるように準備しなければなりません（MUST）。本仕様では、追加の属性タイプのサポートを推奨します。

country 国名、

organization 組織名、

organizational unit 組織単位名、

distinguished name qualifier 識別名修飾子、

state or province name 州または県名、

common name 共通名（例：「Susan Housley」）、および

serial number シリアル番号。

さらに、本仕様の実装は、発行者名および主体名において、以下の標準属性型に対応できるように準備しておくべきである（SHOULD）。

locality 地域、

title 敬称、

surname 姓、

given name 名、

initials イニシャル、

pseudonym 仮名、および

generation gualifier 世代修飾子（例：「Jr.」、「3rd」、「IV」）。

これらの属性型の構文と関連するオブジェクト識別子（OID）は、付録AのASN.1モジュールに規定されている。

証明書利用者は、証明書パス検証（セクション6）のための名前連鎖を実行するために、発行者(issuer)識別名フィールドとサブジェクト(subject)識別名フィールド（セクション4.1.2.6）を処理する準備をしておかなければなりません。名前連鎖は、ある証明書の発行者識別名とCA証明書のサブジェクト名を照合することによって実行されます。識別名の比較規則はセクション7.1に規定されています。証明書の発行者(issuer)フィールドとサブジェクト(subject)フィールドの名前がセクション7.1に規定された規則に従って一致する場合、その証明書は自己発行された証明書です。

4.1.2.5. Validity 有効期間

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

このプロファイルに準拠する CA は、2049 年までの証明書の有効期間を常に UTCTime でエンコードしなければなりません (MUST)。2050 年以降の証明書の有効期間は GeneralizedTime でエンコードしなければなりません (MUST)。

準拠するアプリケーションは、UTCTime または GeneralizedTime のいずれかでエンコードされた有効期間を処理できなければなりません (MUST)。

証明書の有効期間は、notBefore から notAfter までの期間 (両端を含む) です。

状況によっては、有効な有効期限を割り当てられない証明書がデバイスに付与されることがあります。例えば、デバイスには、そのモデル番号とシリアル番号を公開鍵に紐付ける証明書が発行されます。このような証明書は、デバイスの存続期間中ずっと使用されることが想定されています。

証明書に明確な有効期限がないことを示すために、notAfter には GeneralizedTime 値として 99991231235959Z を割り当てる必要があります（SHOULD）。

発行者が notAfter の日付までステータス情報を維持できない場合（notAfter の日付が 99991231235959Z の場合も含む）、発行者はステータス情報の維持が終了した後、証明書に対して有効な認証パスが存在しないようにする必要があります（MUST）。これは、証明書の署名検証に使用された公開鍵を含むすべての CA 証明書を有効期限切れまたは失効させ、証明書の署名検証に使用された公開鍵をトラストアンカーとして使用しないようにすることで実現できます。

4.1.2.5.1. UTCTime

このプロファイルでは、UTCTime の値はグリニッジ標準時 (ズールー標準時) で表現され、秒数が0の場合でも秒数を含める必要があります (つまり、時刻は YYMMDDHHMMSSZ です)。準拠システムは、年フィールド (YY) を以下のように解釈する必要があります。

YY が 50 以上の場合、年は 19YY と解釈され、

YY が 50 未満の場合、年は 20YY と解釈されます。

4.1.2.5.2. GemeralizedTime

このプロファイルでは、GeneralizedTimeの値はグリニッジ標準時（Zulu）で表現されなければならず、秒数が0の場合でも秒数（YYYYMMDDHHMMSSZ）を含める必要があります。GeneralizedTimeの値には、小数秒を含めてはなりません。

4.1.2.6. Subject

Subjectフィールドは、サブジェクト公開鍵フィールドに格納されている公開鍵に関連付けられたエンティティを識別します。サブジェクト名は、サブジェクトフィールドおよび／またはsubjectAltName拡張に格納される場合があります。サブジェクトがCA（例えば、セクション4.2.1.9で説明した基本制約拡張が存在し、cAの値がTRUE）の場合、サブジェクトフィールドには、サブジェクトCAが発行するすべての証明書の発行者フィールド（セクション4.1.2.4）の内容と一致する、空でない識別名が設定されなければなりません（MUST）。サブジェクトがCRL発行者（例えば、セクション4.2.1.3で説明した鍵用途拡張が存在し、cRLSignの値がTRUE）の場合、サブジェクトフィールドには、サブジェクトCRL発行者が発行するすべてのCRLの発行者フィールド（セクション5.1.2.3）の内容と一致する、空でない識別名が設定されなければなりません（MUST）。サブジェクト名情報が subjectAltName 拡張にのみ存在する場合（例：電子メールアドレスまたは URI にのみバインドされたキー）、サブジェクト名は空のシーケンスでなければならず（MUST）、subjectAltName 拡張はクリティカルでなければなりません（MUST）。

subjectAltName が空でない場合、subject フィールドには X.500 識別名（DN）が含まれていなければなりません（MUST）。DN は、発行者フィールドで定義されているように、1 つの CA によって認証される各サブジェクトエンティティごとに一意でなければなりません（MUST）。CA は、同じサブジェクトエンティティに対して、同じ DN を持つ複数の証明書を発行できます（MAY）。

subject フィールドは、X.501 タイプの Name として定義されます。このフィールドの実装要件は、発行者フィールド（セクション 4.1.2.4）に定義されている要件と同じです。本仕様の実装は、発行者フィールドに必要な属性型を含むサブジェクト名に対応していなければなりません（MUST）。また、本仕様の実装は、発行者フィールドの推奨属性型を含むサブジェクト名に対応していなければなりません（SHOULD）。これらの属性タイプの構文と関連するオブジェクト識別子 (OID) は、付録 A の ASN.1 モジュールで提供されています。本仕様の実装では、DirectoryString のエンコードオプションのいずれかを使用する未知の属性タイプ (つまり、名前連鎖用) を処理するために、セクション 7.1 の比較規則を使用できます (MAY)。未知の属性タイプに、DirectoryString で見つからないエンコードオプションを持つ属性値が含まれる場合は、バイナリ比較を使用する必要があります。これにより、実装はサブジェクト名に未知の属性を持つ証明書を処理できます。

DirectoryString タイプの属性値をエンコードする場合、準拠 CA は PrintableString または UTF8String エンコードを使用する必要があります (MUST)。ただし、以下の例外があります。

(a) 証明書のサブジェクトが CA である場合、サブジェクトフィールドは、そのサブジェクト CA が発行するすべての証明書の発行者フィールド (セクション 4.1.2.4) と同じ方法でエンコードする必要があります (MUST)。したがって、サブジェクトCAが発行する証明書の発行者フィールドの属性をTeletexString、BMPString、またはUniversalStringエンコーディングでエンコードする場合、そのCAに発行される証明書のサブジェクトフィールドでも同じエンコーディングを使用する必要があります。

(b) 証明書のサブジェクトがCRL発行者である場合、サブジェクトフィールドは、そのサブジェクトCRL発行者が発行するすべてのCRLの発行者フィールド（セクション5.1.2.3）でエンコードされているのと同じ方法でエンコードする必要があります。

(c) TeletexString、BMPString、およびUniversalStringは下位互換性のために含まれており、新しいサブジェクトの証明書には使用しないでください。ただし、これらのタイプは、名前が既に設定されている証明書では使用できます。これには、既存のサブジェクトに新しい証明書を発行する場合や、エンコードされる属性が他のサブジェクトに発行された証明書で既に設定されている場合に新しいサブジェクトに証明書を発行する場合が含まれます。証明書の利用者は、これらのタイプの証明書を受け取る準備をする必要があります。

電子メールアドレスを含む新しい証明書を生成する準拠実装は、サブジェクト代替名拡張 (セクション 4.2.1.6) の rfc822Name を使用して、そのような ID を記述する必要があります (MUST)。従来の実装をサポートするために、サブジェクト識別名に emailAddress 属性を同時に含めることは非推奨ですが、許可されています。

4.1.2.7. サブジェクト公開鍵情報 Subject Public Key Info

4.1.2.8. 一意の識別子 Unique Identifier

これらのフィールドは、バージョンが2または3（セクション4.1.2.1）の場合にのみ出現する必要があります。バージョンが1の場合は、これらのフィールドは出現してはなりません。サブジェクト名および発行者名の一意の識別子は、サブジェクト名および発行者名が時間の経過とともに再利用される可能性に対応するために証明書に存在します。このプロファイルでは、異なるエンティティ間で名前を再利用しないこと、およびインターネット証明書で一意の識別子を使用しないことを推奨します。このプロファイルに準拠する認証局は、一意の識別子を持つ証明書を生成してはなりません（MUST NOT）。このプロファイルに準拠するアプリケーションは、一意の識別子を含む証明書を解析できる必要があります（SHOULD）が、一意の識別子に関連する処理要件はありません。

4.1.2.9. 拡張機能 Extensions

このフィールドは、バージョンが3（セクション4.1.2.1）の場合にのみ出現しなければなりません。存在する場合、このフィールドは1つ以上の証明書拡張機能のシーケンスです。インターネットPKIにおける証明書拡張機能の形式と内容は、セクション4.2で定義されています。

4.2. 証明書の拡張

X.509 v3証明書用に定義された拡張は、追加属性をユーザーまたは公開鍵に関連付け、CA間の関係を管理するための方法を提供します。X.509 v3証明書フォーマットでは、コミュニティが独自の情報を伝達するためのプライベート拡張を定義することもできます。証明書内の各拡張は、クリティカルまたは非クリティカルのいずれかに指定されます。証明書を使用するシステムは、認識できないクリティカル拡張、または処理できない情報を含むクリティカル拡張を検出した場合、証明書を拒否しなければなりません（MUST）。非クリティカル拡張は、認識されない場合は無視してもよい（MAY）ですが、認識される場合には処理しなければなりません（MUST）。以下のセクションでは、インターネット証明書内で使用される推奨拡張と、情報の標準的な格納場所を示します。コミュニティは追加の拡張を使用することを選択できますが、一般的なコンテキストでの使用を妨げる可能性のあるクリティカル拡張を証明書に採用する際には注意が必要です。

各拡張には、OIDとASN.1構造が含まれます。証明書に拡張機能が含まれる場合、OID はフィールド extnID として表示され、対応する ASN.1 DER エンコード構造はオクテット文字列 extnValue の値となります。証明書には、特定の拡張機能のインスタンスを複数含めることはできません。例えば、証明書には 1 つの Authority Key Identifier 拡張機能 (セクション 4.2.1.1) のみを含めることができます。拡張機能にはブール値「critical」が含まれ、デフォルト値は FALSE です。各拡張機能のテキストは、このプロファイルに準拠する CA の「critical」フィールドに許容される値を指定します。

準拠する CA は、鍵識別子 (key identifiers セクション 4.2.1.1 および 4.2.1.2)、基本制約 (basic constraints セクション 4.2.1.9)、鍵用途 (key usage セクション 4.2.1.3)、および証明書ポリシー (certificate policies セクション 4.2.1.4) 拡張機能をサポートする必要があります。CA が Subject フィールドに空のシーケンスを持つ証明書を発行する場合、Subject Alternative Name 拡張機能 (セクション 4.2.1.6) をサポートする必要があります。残りの拡張機能のサポートはオプションです。準拠CAは、本仕様で規定されていない拡張機能をサポートしても構いません（MAY）。ただし、証明書発行者は、そのような拡張機能を重要とマークすると相互運用性が損なわれる可能性があることに注意してください。

このプロファイルに準拠するアプリケーションは、少なくとも以下の拡張機能を認識しなければなりません（MUST）。鍵用途（key usage セクション4.2.1.3）、証明書ポリシー（certificate policies セクション4.2.1.4）、サブジェクト代替名（subject alternative name セクション4.2.1.6）、基本制約（basic constraints セクション4.2.1.9）、名前制約（name constraints セクション4.2.1.10）、ポリシー制約（policy constraints セクション4.2.1.11）、拡張鍵用途（extended key usage セクション4.2.1.12）、およびanyPolicyの禁止（inhibit anyPolicy セクション4.2.1.14）。

さらに、このプロファイルに準拠するアプリケーションは、機関とサブジェクトキー識別子 (authority と subject key identifier セクション 4.2.1.1 と 4.2.1.2) およびポリシー マッピング ( policy mappings セクション 4.2.1.5) の拡張を認識する必要があります。

4.2.1. 標準拡張

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

4.2.1.1. 認証局鍵識別子

認証局鍵識別子拡張は、証明書の署名に使用された秘密鍵に対応する公開鍵を識別する手段を提供します。この拡張は、発行者が複数の署名鍵を持つ場合（複数の同時鍵ペアが存在する場合、または鍵交換など）に使用されます。識別は、鍵識別子（発行者の証明書のサブジェクト鍵識別子）または発行者名とシリアル番号のいずれかに基づいて行うことができます。

認証局鍵識別子拡張のkeyIdentifierフィールドは、認証パスの構築を容易にするために、適合認証局によって生成されるすべての証明書に含まれていなければなりません（MUST）。ただし、例外が1つあります。認証局が公開鍵を「自己署名」証明書の形式で配布する場合、認証局鍵識別子は省略できます。自己署名証明書の署名は、証明書のサブジェクト公開鍵に関連付けられた秘密鍵を使用して生成されます（これは、発行者が公開鍵と秘密鍵の両方を所有していることを証明します）。この場合、サブジェクト鍵識別子と認証局鍵識別子は同一になりますが、認証パスの構築にはサブジェクト鍵識別子のみが必要です。

keyIdentifier フィールドの値は、証明書の署名検証に使用された公開鍵、または一意の値を生成する方法から導出されるべきです（SHOULD）。公開鍵から鍵識別子を生成する一般的な2つの方法については、セクション4.2.1.2で説明しています。鍵識別子が以前に確立されていない場合、本仕様では、これらの方法のいずれか、または異なるハッシュアルゴリズムを使用する同様の方法を使用してkeyIdentifierを生成することを推奨します。鍵識別子が以前に確立されている場合、CAは以前に確立された識別子を使用すべきです（SHOULD）。

本プロファイルでは、すべての証明書ユーザーが鍵識別子方式をサポートすることを推奨します。

準拠CAは、この拡張を非クリティカルとしてマークする必要があります（MUST）。

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

code:AuthorityKeyIdentifier

AuthorityKeyIdentifier ::= SEQUENCE {

KeyIdentifier ::= OCTET STRING

4.2.1.2. サブジェクト鍵識別子 Subbject Key Identifier

サブジェクト鍵識別子拡張は、特定の公開鍵を含む証明書を識別する手段を提供します。

認証パスの構築を容易にするため、この拡張はすべての適合CA証明書、すなわち、基本制約拡張（セクション4.2.1.9）を含む、cAの値がTRUEであるすべての証明書に記述されなければなりません（MUST）。適合CA証明書において、サブジェクト鍵識別子の値は、この証明書のサブジェクトが発行した証明書の認証局鍵識別子拡張（セクション4.2.1.1）の鍵識別子フィールドに格納されている値と一致しなければなりません（MUST）。アプリケーションは、認証パス検証を行う際に、鍵識別子が一致することを検証する必要はありません。

CA証明書の場合、サブジェクト鍵識別子は、公開鍵または一意の値を生成する方法から導出されるべきです（SHOULD）。公開鍵から鍵識別子を生成する一般的な方法は2つあります。

(1) 鍵識別子は、ビット列 subjectPublicKey の値（タグ、長さ、未使用ビット数を除く）の160ビットのSHA-1ハッシュで構成されます。

(2) 鍵識別子は、値0100を持つ4ビットの型フィールドと、それに続くビット列 subjectPublicKey の値（タグ、長さ、未使用ビット数を除く）のSHA-1ハッシュの下位60ビットで構成されます。

一意の番号を生成する他の方法も許容されます。

エンドエンティティ証明書の場合、サブジェクト鍵識別子拡張は、アプリケーションで使用される特定の公開鍵を含む証明書を識別する手段を提供します。エンドエンティティが複数の証明書（特に複数のCAから）を取得している場合、サブジェクト鍵識別子は、特定の公開鍵を含む証明書セットを迅速に識別する手段を提供します。アプリケーションが適切なエンドエンティティ証明書を識別できるように、この拡張はすべてのエンドエンティティ証明書に含める必要があります（SHOULD）。

エンドエンティティ証明書の場合、サブジェクト鍵識別子は公開鍵から生成されるべきです（SHOULD）。公開鍵から鍵識別子を生成する一般的な2つの方法は、上記で示されています。

鍵識別子が以前に確立されていない場合、本仕様では、これらの方法のいずれか、または異なるハッシュアルゴリズムを用いた同様の方法を用いて鍵識別子を生成することを推奨します。鍵識別子が以前に確立されている場合、CAは以前に確立された識別子を使用すべきです（SHOULD）。

準拠CAは、この拡張を非クリティカル(non-critical)としてマークしなければなりません（MUST）。

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

SubjectKeyIdentifier ::= KeyIdentifier

4.2.1.3. 鍵用途 Key Usage

鍵用途拡張は、証明書に含まれる鍵の用途（暗号化、署名、証明書への署名など​​）を定義します。鍵用途拡張は、複数の操作に使用可能な鍵を制限したい場合に用いられます。例えば、RSA鍵を公開鍵証明書およびCRL以外のオブジェクトの署名検証にのみ使用する場合、digitalSignatureビットおよび/またはnonRepudiationビットが有効になります。同様に、RSA鍵を鍵管理にのみ使用する場合、keyEnciphermentビットが有効になります。

準拠認証局（CA）は、他の公開鍵証明書またはCRLのデジタル署名の検証に使用される公開鍵を含む証明書に、この拡張を含める必要があります（MUST）。この拡張が存在する場合、準拠認証局（CA）はこれを重要（critical）としてマークする必要があります（SHOULD）。

code:KeyUsage

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

KeyUsage ::= BIT STRING {

digitalSignature (0),

nonRepudiation (1), -- 最近の X.509 版では、このビットは

-- contentCommitment に名称変更されています

keyEncipherment (2),

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6),

encipherOnly (7),

decipherOnly (8) }

KeyUsage 型のビットは以下のように使用されます。

digitalSignature ビットは、サブジェクト公開鍵が、証明書（ビット 5）および CRL（ビット 6）の署名以外のデジタル署名（エンティティ認証サービス、データ発信元認証サービス、および/または整合性サービスで使用されるものなど）の検証に使用される場合にアサートされます。

nonRepudiationビットは、サブジェクト公開鍵が、証明書（ビット5）およびCRL（ビット6）の署名以外のデジタル署名の検証に使用される場合にアサートされます。これらの署名は、署名者が何らかのアクションを誤って否定することを防ぐ否認防止サービスとして使用されます。後日、紛争が発生した場合、信頼できる第三者が署名データの真正性を判断できます。（X.509の最近の版では、nonRepudiationビットがcontentCommitmentに名称変更されていることに注意してください。）

keyEnciphermentビットは、サブジェクト公開鍵が秘密鍵または秘密情報鍵の暗号化、つまり鍵転送に使用される場合にアサートされます。例えば、RSA公開鍵を対称コンテンツ復号鍵または非対称秘密鍵の暗号化に使用する場合は、このビットを設定する必要があります。

dataEnciphermentビットは、サブジェクト公開鍵が中間対称暗号を使用せずに生のユーザーデータを直接暗号化するために使用される場合にアサートされます。このビットの使用は極めて稀であることに注意してください。ほとんどすべてのアプリケーションは、対称鍵を確立するために鍵転送または鍵合意を使用します。

keyAgreementビットは、サブジェクト公開鍵が鍵合意に使用される場合にアサートされます。例えば、鍵管理にDiffie-Hellman鍵を使用する場合、このビットは設定されます。

keyCertSignビットは、サブジェクト公開鍵が公開鍵証明書の署名検証に使用される場合にアサートされます。keyCertSignビットがアサートされている場合、基本制約拡張（セクション4.2.1.9）のcAビットもアサートされなければなりません。

cRLSignビットは、サブジェクト公開鍵が証明書失効リスト（CRL、Delta CRL、ARLなど）の署名検証に使用される場合にアサートされます。

keyAgreementビットがない場合、encipherOnlyビットの意味は未定義です。 encipherOnlyビットがアサートされ、keyAgreementビットもセットされている場合、サブジェクト公開鍵は鍵合意の実行中にデータの暗号化にのみ使用できます。

keyAgreementビットがない場合、decipherOnlyビットの意味は未定義です。decipherOnlyビットがアサートされ、keyAgreementビットもセットされている場合、サブジェクト公開鍵は鍵合意の実行中にデータの復号にのみ使用できます。

keyUsage 拡張が存在する場合、対応する keyCertSign または cRLSign ビットが設定されていない限り、サブジェクト公開鍵は証明書または CRL の署名検証に使用してはなりません（MUST NOT）。サブジェクト公開鍵が証明書および/または CRL の署名検証にのみ使用される場合、digitalSignature ビットおよび nonRepudiation ビットは設定すべきではありません（SHOULD NOT）。ただし、サブジェクト公開鍵が証明書および/または CRL だけでなく他のオブジェクトの署名検証にも使用される場合は、keyCertSign ビットおよび/または cRLSign ビットに加えて、digitalSignature ビットおよび/または nonRepudiation ビットを設定することができます（MAY）。

keyUsage 証明書拡張の nonRepudiation ビットを他の keyUsage ビットと組み合わせると、証明書が使用されるコンテキストによってはセキュリティに影響が生じる可能性があります。digitalSignature ビットと nonRepudiation ビットの詳細な区別は、特定の証明書ポリシーで規定される場合があります。

4.2.1.4. 証明書ポリシー Certificate Policies

証明書ポリシー拡張には、1つ以上のポリシー情報用語のシーケンスが含まれます。各ポリシー情報用語は、オブジェクト識別子 (OID) とオプションの修飾子で構成されます。オプションの修飾子は存在しても構いませんが、ポリシーの定義を変更するものではありません。証明書ポリシーOIDは、証明書ポリシー拡張内で複数回出現してはなりません。

エンドエンティティ証明書では、これらのポリシー情報用語は、証明書が発行されたポリシーと、証明書の使用目的を示します。CA証明書では、これらのポリシー情報用語は、この証明書を含む認証パスのポリシーセットを制限します。CAがこの証明書を含む認証パスのポリシーセットを制限したくない場合は、特別なポリシー anyPolicy を {2 5 29 32 0 } の値でアサートすることができます。

特定のポリシー要件を持つアプリケーションは、受け入れるポリシーのリストを保持し、証明書内のポリシーOIDをそのリストと比較することが期待されます。この拡張がクリティカルな場合、パス検証ソフトウェアはこの拡張（オプションの修飾子を含む）を解釈できなければならず（MUST）、解釈できない場合は証明書を拒否しなければなりません（MUST）。

相互運用性を促進するため、本プロファイルでは、ポリシー情報条項はOIDのみで構成することを推奨します。OIDだけでは不十分な場合、本プロファイルでは、修飾子の使用を本セクションで特定されるものに限定することを強く推奨します。特殊ポリシー anyPolicy で修飾子を使用する場合は、本セクションで特定される修飾子に限定しなければなりません（MUST）。パス検証の結果として返される修飾子のみが考慮されます。

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

CPSポインタ修飾子には、CAが発行する認証局運用規定（CPS）へのポインタが含まれます。このポインタはURI形式です。この修飾子の処理要件はローカルな問題です。拡張機能に対してアサートされた重要度値に関係なく、この仕様ではアクションは必須ではありません。

ユーザー通知は、証明書の使用時に証明書利用者に表示されるものです。パス検証の結果として返されたユーザー通知のみがユーザーに表示されます。通知が重複している場合は、1部のみ表示する必要があります。このような重複を防ぐため、この修飾子はエンドエンティティ証明書および他の組織に発行されたCA証明書にのみ存在する必要があります（SHOULD）。

ユーザー通知には、noticeRefフィールドとexplicitTextフィールドという2つのオプションフィールドがあります。準拠CAはnoticeRefオプションを使用すべきではありません（SHOULD NOT）。

noticeRefフィールドを使用する場合、組織名と、その組織が作成した特定のテキストステートメントを番号で識別します。例えば、組織名「CertsRUs」と通知番号1を識別します。一般的な実装では、アプリケーションソフトウェアはCertsRUsの最新の通知セットを含む通知ファイルを保持し、アプリケーションはそのファイルから通知テキストを抽出して表示します。メッセージは多言語であってもよく、ソフトウェアは自身の環境に合わせて特定の言語メッセージを選択できます。

noticeRefオプションとexplicitTextオプションの両方が1つの修飾子に含まれており、アプリケーションソフトウェアがnoticeRefオプションで指定された通知テキストを見つけることができる場合は、そのテキストを表示すべきです（SHOULD）。そうでない場合は、明示的テキスト文字列を表示すべきです（SHOULD）。

注: 明示的テキストの最大文字数は200文字ですが、一部の非準拠CAはこの制限を超えています。したがって、証明書の利用者は、200文字を超える明示的テキストを適切に処理する必要があります。

code:policies

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. ポリシーマッピング Policy Mapping

この拡張はCA証明書で使用されます。この拡張は、1つ以上のOIDペアを列挙します。各ペアには、issuerDomainPolicyとsubjectDomainPolicyが含まれます。このペアは、発行CAが自身のissuerDomainPolicyをサブジェクトCAのsubjectDomainPolicyと同等とみなしていることを示します。

発行CAのユーザーは、特定のアプリケーションに対してissuerDomainPolicyを受け入れる場合があります。ポリシーマッピングは、サブジェクトCAに関連付けられ、issuerDomainPolicyと同等として受け入れられる可能性のあるポリシーのリストを定義します。

ポリシーマッピング拡張で指定された各issuerDomainPolicyは、同じ証明書の証明書ポリシー拡張でもアサートされるべきです（SHOULD）。ポリシーは、特別な値anyPolicy（セクション4.2.1.4）との間でマッピングしてはなりません（MUST NOT）。

一般的に、ポリシーマッピング拡張のissuerDomainPolicyフィールドに記載される証明書ポリシーは、認証パス内の後続の証明書に含めることが許容されるポリシーとは見なされません。状況によっては、CAが1つのポリシー（p1）から別のポリシー（p2）にマッピングしたいものの、後続の証明書にはissuerDomainPolicy（p1）を含めることを許容したい場合があります。これは、例えば、CAがポリシーp1の使用からポリシーp2の使用への移行過程にあり、それぞれのポリシーに基づいて発行された有効な証明書を保有している場合などに発生します。CAは、発行するCA証明書に2つのポリシーマッピングを含めることで、このことを示すことができます。各ポリシーマッピングのissuerDomainPolicyはp1です。一方のポリシーマッピングのsubjectDomainPolicyはp1、もう一方のポリシーマッピングのsubjectDomainPolicyはp2です。

この拡張は、CAおよび／またはアプリケーションによってサポートされる場合があります（MAY）。準拠CAは、この拡張をクリティカルとしてマークする必要があります（SHOULD）。

code:policyMapping

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

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

issuerDomainPolicy CertPolicyId,

subjectDomainPolicy CertPolicyId }

4.2.1.6. サブジェクト代替名 Subject Alternative Name

サブジェクト代替名拡張により、証明書のサブジェクトにIDを結び付けることができます。これらのIDは、証明書のサブジェクトフィールドのIDに加えて、またはIDの代わりに含めることができます。定義済みのオプションには、インターネット電子メールアドレス、DNS名、IPアドレス、Uniform Resource Identifier (URI) などがあります。完全にローカルな定義を含むその他のオプションも存在します。複数の名前形式、および各名前形式の複数のインスタンスを含めることができます。このようなIDを証明書に結び付ける場合は、必ずサブジェクト代替名（または発行者代替名）拡張を使用する必要があります。ただし、セクション4.1.2.4で説明されているように、domainComponent属性を使用して、サブジェクトフィールドにDNS名を表すこともできます。サブジェクトフィールドにこのような名前を表す場合、実装はそれらをDNS名に変換する必要がないことに注意してください。

サブジェクト代替名は公開鍵に明確に結び付けられているとみなされるため、サブジェクト代替名のすべての部分はCAによって検証されなければなりません。

さらに、証明書に含まれるサブジェクト識別情報が代替名形式（例：電子メールアドレス）のみである場合、サブジェクト識別名は空（空シーケンス）でなければならず、subjectAltName拡張が存在しなければなりません。サブジェクトフィールドに空シーケンスが含まれる場合、発行CAはcritical（重要）とマークされたsubjectAltName拡張を含める必要があります。空でないサブジェクト識別名を持つ証明書にsubjectAltName拡張を含める場合、準拠CAはsubjectAltName拡張をnon-critical（重要でない）とマークする必要があります（SHOULD）。

subjectAltName拡張にドメインネームシステムラベルが含まれる場合、ドメイン名はdNSName（IA5String）に格納されなければなりません（MUST）。

subjectAltName 拡張の directoryName に DN が含まれる場合、エンコード規則はセクション 4.1.2.4 の発行者フィールドに規定されている規則と同じです。DN は、発行者フィールドで定義される単一の CA によって認証される各サブジェクトエンティティに対して一意でなければなりません（MUST）。CA は、同一のサブジェクトエンティティに対して、同一の DN を持つ複数の証明書を発行することができます（MAY）。

サブジェクト代替名は、セクション 4.2.1.10 で説明されている名前制約拡張を使用して、サブジェクト識別名と同じ方法で制約できます。

subjectAltName 拡張が存在する場合、シーケンスには少なくとも 1 つのエントリが含まれていなければなりません (MUST)。サブジェクトフィールドとは異なり、準拠 CA は、空の GeneralName フィールドを含む subjectAltName を持つ証明書を発行してはなりません (MUST NOT)。例えば、rfc822Name は IA5String として表現されます。空の文字列は有効な IA5String ですが、このような rfc822Name はこのプロファイルでは許可されません。認証パスの処理中にこのような証明書に遭遇したクライアントの動作は、このプロファイルでは定義されません。

最後に、ワイルドカード文字を含むサブジェクト代替名（例えば、名前セットのプレースホルダとして使用されるもの）の意味については、本仕様では扱いません。特定の要件を持つアプリケーションでは、このような名前を使用できますが、意味を定義する必要があります。

code:subjectAltName

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

SubjectAltName ::= GeneralNames

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

GeneralName ::= CHOICE {

OtherName ::= SEQUENCE {

type-id OBJECT IDENTIFIER,

EDIPartyName ::= SEQUENCE {

4.2.1.7. 発行者代替名 Issuer Alternative Name

セクション4.2.1.6と同様に、この拡張機能はインターネット形式のアイデンティティと証明書発行者を関連付けるために使用されます。発行者代替名は、セクション6の証明書パス検証アルゴリズムの一部として処理されません。（つまり、発行者代替名は名前連鎖には使用されず、名前制約も適用されません。）

適合CAは、この拡張機能が存在する場合、これを非重要としてマークする必要があります（SHOULD）。

code:issuerAltName

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

IssuerAltName ::= GeneralNames

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

サブジェクトディレクトリ属性拡張は、サブジェクトの識別属性（例：国籍）を伝達するために使用されます。この拡張は、1つ以上の属性のシーケンスとして定義されます。準拠CAは、この拡張を非クリティカルとしてマークする必要があります。

code:subjectDirectoryAttributes

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

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

4.2.1.9. 基本制約

基本制約拡張は、証明書の主体が認証局であるかどうか、およびこの証明書を含む有効な認証パスの最大深度を識別します。

cAブール値は、認証済み公開鍵が証明書署名の検証に使用できるかどうかを示します。cAブール値がアサートされていない場合、鍵用途拡張のkeyCertSignビットはアサートされてはいけません（MUST NOT）。バージョン3の証明書に基本制約拡張が存在しない場合、または基本制約拡張は存在するもののcAブール値がアサートされていない場合、認証済み公開鍵は証明書署名の検証に使用してはいけません（MUST NOT）。

pathLenConstraintフィールドは、cAブール値がアサートされ、かつ鍵用途拡張（存在する場合）がkeyCertSignビットをアサートしている場合にのみ意味を持ちます（セクション4.2.1.3）。この場合、pathLenConstraintフィールドは、有効な認証パスにおいてこの証明書に続くことができる非自己発行の中間証明書の最大数を示します。 （注：認証パスの最後の証明書は中間証明書ではないため、この制限には含まれません。通常、最後の証明書はエンドエンティティ証明書ですが、CA証明書の場合もあります。）pathLenConstraintが0の場合、有効な認証パスには自己発行ではない中間CA証明書が続くことはできません。pathLenConstraintフィールドが指定されている場合、pathLenConstraintフィールドは0以上でなければなりません（MUST）。pathLenConstraintが指定されていない場合、制限は課されません。

準拠CAは、証明書のデジタル署名の検証に使用される公開鍵を含むすべてのCA証明書にこの拡張を含める必要があり（MUST）、そのような証明書ではこの拡張をクリティカルとしてマークする必要があります（MUST）。この拡張は、証明書のデジタル署名の検証以外の目的で使用される公開鍵を含むCA証明書では、クリティカルまたは非クリティカルの拡張として指定できます（MAY）。このようなCA証明書には、CRLのデジタル署名の検証に使用される公開鍵を含む証明書や、証明書登録プロトコルで使用される鍵管理用公開鍵を含む証明書が含まれます。この拡張は、エンドエンティティ証明書において、クリティカル拡張または非クリティカル拡張として記述される場合があります。

CA は、cA ブール値がアサートされ、かつ鍵用途拡張で keyCertSign ビットがアサートされない限り、pathLenConstraint フィールドを含めてはなりません（MUST NOT）。

code:basicConstraints

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

BasicConstraints ::= SEQUENCE {

cA BOOLEAN DEFAULT FALSE,

pathLenConstraint INTEGER (0..MAX) OPTIONAL }

4.2.1.10. 名前制約

名前制約拡張は、CA証明書でのみ使用する必要があります。これは、認証パス内の後続の証明書に含まれるすべてのサブジェクト名が属する名前空間を示します。制約は、サブジェクト識別名とサブジェクト代替名に適用されます。制約は、指定された名前形式が存在する場合にのみ適用されます。証明書に指定された形式の名前がない場合、証明書は受理可能です。

名前制約は、自己発行証明書には適用されません（ただし、証明書がパス内の最後の証明書である場合は除きます）。（これにより、名前制約を使用するCAが、自己発行証明書を使用して鍵ロールオーバーを実装できない可能性があります。）

制約は、許可または除外される名前サブツリーによって定義されます。excludedSubtreesフィールドの制約に一致する名前は、permittedSubtreesフィールドの情報に関係なく無効です。準拠CAは、この拡張を重要（critical）としてマークしなければならず（MUST）、x400Address、ediPartyName、またはregisteredIDの名前形式に名前制約を課すべきではありません（SHOULD NOT）。準拠CAは、名前制約が空のシーケンスである証明書を発行してはなりません（MUST NOT）。つまり、permittedSubtreesフィールドまたはexcludedSubtreesフィールドのいずれかが存在しなければなりません（MUST）。

このプロファイルに準拠するアプリケーションは、directoryName名前形式に課される名前制約を処理できなければならず（MUST）、rfc822Name、uniformResourceIdentifier、dNSName、およびiPAddress名前形式に課される名前制約を処理できるべきです（SHOULD）。重要（critical）としてマークされた名前制約拡張が特定の名前形式に制約を課し、その名前形式のインスタンスが後続の証明書のサブジェクトフィールドまたはsubjectAltName拡張に出現する場合、アプリケーションは制約を処理するか、証明書を拒否しなければなりません（MUST）。このプロファイルでは、最小値フィールドと最大値フィールドはどの名前形式にも使用されません。したがって、最小値は0でなければならず、最大値は存在してはなりません（SHOULD）。ただし、アプリケーションが、後続の証明書に表示される名前形式の最小値または最大値に他の値を指定する重要な名前制約拡張に遭遇した場合、アプリケーションはこれらのフィールドを処理するか、証明書を拒否する必要があります。

URIの場合、制約は名前のホスト部分に適用されます。制約は完全修飾ドメイン名で指定する必要があり、ホストまたはドメインを指定することもできます。例としては、「host.example.com」と「.example.com」が挙げられます。制約がピリオドで始まる場合、1つ以上のラベルで拡張できます。つまり、「.example.com」という制約は、host.example.comとmy.host.example.comの両方で満たされます。ただし、「.example.com」という制約は、「example.com」では満たされません。制約がピリオドで始まらない場合は、ホストを指定します。制約がuniformResourceIdentifierの名前形式に適用され、後続の証明書に、ホスト名が完全修飾ドメイン名で指定された権限コンポーネントを含まないuniformResourceIdentifierを持つsubjectAltName拡張子が含まれる場合（例えば、URIに権限コンポーネントが含まれていないか、ホスト名がIPアドレスで指定された権限コンポーネントが含まれている場合）、アプリケーションは証明書を拒否する必要があります（MUST）。

インターネットメールアドレスの名前制約は、特定のメールボックス、特定のホストのすべてのアドレス、またはドメイン内のすべてのメールボックスを指定できます。特定のメールボックスを指定する場合、制約はメールアドレス全体となります。例えば、「root@example.com」はホスト「example.com」のルートメールボックスを示します。特定のホスト上のすべてのインターネットメールアドレスを指定する場合、制約はホスト名で指定します。例えば、「example.com」という制約は、ホスト「example.com」の任意のメールアドレスで満たされます。ドメイン内の任意のアドレスを指定する場合、制約はURIと同様に先頭にピリオドを付けて指定します。例えば、「.example.com」はドメイン「example.com」内のすべてのインターネットメールアドレスを示しますが、ホスト「example.com」のインターネットメールアドレスは示しません。

DNS名制約はhost.example.comのように表現されます。名前の左側に0個以上のラベルを追加するだけで構成できるDNS名はすべて、名前制約を満たします。例えば、www.host.example.comは制約を満たしますが、host1.example.comは満たしません。

従来の実装では、電子メールアドレスが emailAddress 型の属性のサブジェクト識別名に埋め込まれています（セクション 4.1.2.6）。rfc822Name の名前形式に制約が課されているものの、証明書にサブジェクト代替名が含まれていない場合、rfc822Name の制約はサブジェクト識別名の emailAddress 型の属性に適用されなければなりません（MUST）。emailAddress の ASN.1 構文と対応する OID は付録 A に記載されています。

directoryName 形式の制約は、証明書のサブジェクトフィールド（証明書に空でないサブジェクトフィールドが含まれている場合）と、subjectAltName 拡張内の directoryName 型の名前に適用されなければなりません（MUST）。x400Address 形式の制約は、subjectAltName 拡張内の x400Address 型の名前に適用されなければなりません（MUST）。

directoryName 形式の制約を適用する場合、実装は DN 属性を比較しなければなりません（MUST）。少なくとも、実装はセクション 7.1 で規定されている DN 比較規則を実行しなければなりません（MUST）。 directoryName 形式の制約を伴う証明書を発行する CA は、完全な ISO DN 名比較アルゴリズムの実装に依存すべきではありません。これは、名前制約が、サブジェクトフィールドまたは subjectAltName 拡張で使用されるエンコーディングと同一の形式で記述されなければならないことを意味します。

名前制約のエンコードと処理に関する追加ルールは、セクション7で規定されています。

otherName、ediPartyName、およびregisteredIDの名前制約の構文とセマンティクスは、この仕様では定義されていませんが、他の名前形式の名前制約の構文とセマンティクスは、他の文書で規定される場合があります。

code:nameConstraints

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

NameConstraints ::= SEQUENCE {

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

GeneralSubtree ::= SEQUENCE {

base GeneralName,

BaseDistance ::= INTEGER (0..MAX)

4.2.1.11. ポリシー制約

ポリシー制約拡張は、CA に発行される証明書で使用できます。ポリシー制約拡張は、パスの検証を 2 つの方法で制約します。ポリシーマッピングを禁止するか、パス内の各証明書に許容可能なポリシー識別子が含まれていることを要求できます。

inhibitPolicyMapping フィールドが存在する場合、その値は、ポリシーマッピングが許可されなくなるまでにパスに出現できる追加の証明書の数を示します。たとえば、値が 1 の場合、この証明書の主体によって発行された証明書ではポリシーマッピングが処理されますが、パス内の追加の証明書ではポリシーマッピングは処理されません。

requireExplicitPolicy フィールドが存在する場合、requireExplicitPolicy の値は、パス全体に明示的なポリシーが必要となるまでにパスに出現できる追加の証明書の数を示します。明示的なポリシーが必要な場合、パス内のすべての証明書の証明書ポリシー拡張に許容可能なポリシー識別子が含まれている必要があります。許容されるポリシー識別子とは、証明書パスの利用者が要求するポリシーの識別子、またはポリシーマッピングによって同等であると宣言されたポリシーの識別子です。

準拠アプリケーションは、requireExplicitPolicyフィールドを処理できなければならず（MUST）、また、inhibitPolicyMappingフィールドも処理できるべきです（SHOULD）。inhibitPolicyMappingフィールドをサポートするアプリケーションは、policyMappings拡張のサポートも実装しなければなりません（MUST）。policyConstraints拡張がcriticalとしてマークされ、inhibitPolicyMappingフィールドが存在する場合、inhibitPolicyMappingフィールドのサポートを実装していないアプリケーションは、証明書を拒否しなければなりません（MUST）。

準拠CAは、ポリシー制約が空のシーケンスである証明書を発行してはなりません（MUST NOT）。つまり、inhibitPolicyMappingフィールドまたはrequireExplicitPolicyフィールドのいずれかが存在しなければなりません（MUST）。空のポリシー制約フィールドを検出したクライアントの動作については、このプロファイルでは規定されていません。

準拠CAは、この拡張をcriticalとしてマークしなければなりません（MUST）。

code:policyConstraints

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

PolicyConstraints ::= SEQUENCE {

SkipCerts ::= INTEGER (0..MAX)

4.2.1.12. 拡張鍵用途

この拡張機能は、鍵用途拡張機能で示される基本的な用途に加えて、または基本的な用途に代えて、認証済み公開鍵が使用される1つ以上の用途を示します。通常、この拡張機能はエンドエンティティ証明書にのみ使用されます。この拡張機能は以下のように定義されます。

code:extKeyUsage

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

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

KeyPurposeId ::= OBJECT IDENTIFIER

この拡張は、証明書発行者の選択により、クリティカルまたは非クリティカルのいずれかにすることができます（MAY）。

この拡張が存在する場合、証明書は指定された用途のうちの1つの用途にのみ使用されなければなりません（MAY）。複数の用途が指定されている場合、意図された用途が存在する限り、アプリケーションは指定されたすべての用途を認識する必要はありません。証明書を使用するアプリケーションは、証明書がアプリケーションに受け入れられるために、拡張鍵用途拡張が存在し、特定の用途が指定されていることを要求できます（MAY）。

CA がそのようなアプリケーションに対応するために拡張鍵用途を組み込んでいるものの、鍵の用途を制限したくない場合は、CA はアプリケーションが要求する特定の鍵用途に加えて、特別な KeyPurposeId である anyExtendedKeyUsage を含めることができます。準拠CAは、anyExtendedKeyUsage KeyPurposeIdが存在する場合、この拡張をクリティカルとしてマークしないでください。特定の目的の存在を必要とするアプリケーションは、anyExtendedKeyUsage OIDを含むものの、アプリケーションに期待される特定のOIDを含まない証明書を拒否する場合があります。

証明書に鍵用途拡張と拡張鍵用途拡張の両方が含まれている場合、両方の拡張は独立して処理されなければならず（MUST）、証明書は両方の拡張と一致する目的にのみ使用されなければなりません（MUST）。両方の拡張と一致する目的がない場合、証明書はいかなる目的にも使用してはなりません（MUST）。

以下の鍵用途目的が定義されています。

code:anyExtendedKeyUsage

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

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

id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }

-- TLS WWW server authentication

-- 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配布ポイント

CRL配布ポイント拡張は、CRL情報の取得方法を指定します。この拡張は重要ではないことが望ましいですが、本プロファイルでは、CAおよびアプリケーションによるこの拡張のサポートを推奨します。

CRL管理に関する詳細な説明は、セクション5に記載されています。

cRLDistributionPoints 拡張は、DistributionPoint の SEQUENCE です。DistributionPoint は、distributionPoint、reasons、cRLIssuer の 3 つのフィールドで構成され、各フィールドはオプションです。これらのフィールドはそれぞれオプションですが、DistributionPoint は、reasons フィールドのみで構成してはなりません。distributionPoint または cRLIssuer のいずれかが必須です。証明書発行者が CRL 発行者でない場合は、cRLIssuer フィールドが存在し、CRL 発行者の Name が含まれている必要があります。証明書発行者が CRL 発行者でもある場合は、準拠 CA は cRLIssuer フィールドを省略し、distributionPoint フィールドを含める必要があります。

distributionPoint フィールドが存在する場合、このフィールドには、一般名の SEQUENCE または単一の値 nameRelativeToCRLIssuer が含まれます。DistributionPointName に複数の値が含まれる場合、それぞれの名前は同じ CRL を取得するための異なるメカニズムを表します。例えば、同じ CRL を LDAP と HTTP の両方で取得できる場合があります。

distributionPoint フィールドに directoryName が含まれる場合、その directoryName のエントリには、関連付けられた理由に基づく現在の CRL が含まれており、その CRL は関連付けられた cRLIssuer によって発行されます。CRL は、certificateRevocationList 属性またはauthorityRevocationList 属性のいずれかに格納されます。CRL は、アプリケーションがローカルに設定されているディレクトリサーバーから取得されます。アプリケーションがディレクトリへのアクセスに使用するプロトコル（DAP や LDAP など）は、ローカルで管理されます。

DistributionPointName に単一の値 nameRelativeToCRLIssuer が含まれる場合、その値は識別名フラグメントを提供します。フラグメントはCRL発行者のX.500識別名に追加され、配布ポイント名を取得します。DistributionPointにcRLIssuerフィールドが存在する場合、名前フラグメントはその識別名に追加されます。そうでない場合、名前フラグメントは証明書発行者の識別名に追加されます。準拠CAは、配布ポイント名を指定するためにnameRelativeToCRLIssuerを使用すべきではありません。cRLIssuerに複数の識別名が含まれている場合、DistributionPointNameはnameRelativeToCRLIssuerの代替フィールドを使用してはなりません（MUST NOT）。

DistributionPointが理由フィールドを省略する場合、CRLにはすべての理由の失効情報を含める必要があります（MUST）。本プロファイルでは、CRLを理由コードで分割しないことを推奨します。準拠CAが証明書にcRLDistributionPoints拡張を含める場合、すべての理由において証明書を対象とするCRLを指すDistributionPointを少なくとも1つ含める必要があります（MUST）。

cRLIssuerは、CRLに署名および発行するエンティティを識別します。 cRLIssuer が存在する場合、そのフィールドには、DistributionPoint が指している CRL の issuer フィールドの識別名 (DN) のみを含める必要があります。cRLIssuer フィールドの名前のエンコーディングは、CRL の issuer フィールドのエンコーディングと完全に一致する必要があります。cRLIssuer フィールドが含まれていて、そのフィールドの DN が CRL が配置されている X.500 または LDAP ディレクトリエントリと一致しない場合、準拠 CA は distributionPoint フィールドを含める必要があります。

code:cRLDistributionPoints

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

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

DistributionPoint ::= SEQUENCE {

DistributionPointName ::= CHOICE {

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. anyPolicy の禁止

inhibit anyPolicy 拡張は、CA に発行される証明書で使用できます。inhibit anyPolicy 拡張は、値が { 2 5 29 32 0 } である特別な anyPolicy OID が、中間の自己発行 CA 証明書に出現する場合を除き、他の証明書ポリシーと明示的に一致しないことを示します。この値は、パス内に出現できる自己発行ではない証明書の数が、anyPolicy が許容されなくなるまでの数を示します。例えば、値が 1 の場合、この証明書のサブジェクトが発行した証明書では anyPolicy が処理される可能性がありますが、パス内の他の証明書では処理されないことを示します。

準拠 CA は、この拡張を「critical」としてマークする必要があります。

code:inhibitAnyPolicy

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

InhibitAnyPolicy ::= SkipCerts

SkipCerts ::= INTEGER (0..MAX)

4.2.1.15. 最新のCRL（別名：Delta CRL配布ポイント）

最新のCRL拡張は、Delta CRL情報の取得方法を指定します。適合CAは、この拡張を非クリティカルとしてマークする必要があります。CRL管理の詳細については、セクション5を参照してください。

この拡張とcRLDistributionPoints拡張には同じ構文が使用され、セクション4.2.1.13で説明されています。両方の拡張に同じ規則が適用されます。

code:freshestCRL

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

FreshestCRL ::= CRLDistributionPoints

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

このセクションでは、インターネット公開鍵基盤（PKI）で使用する2つの拡張を定義します。これらの拡張は、発行者または主体に関するオンライン情報にアプリケーションを誘導するために使用できます。各拡張には、アクセス方法とアクセス場所のシーケンスが含まれます。アクセス方法は、利用可能な情報の種類を示すオブジェクト識別子です。アクセス場所は、情報の場所と形式、および情報の取得方法を暗黙的に指定するGeneralNameです。

オブジェクト識別子は、プライベート拡張に対して定義されます。プライベート拡張に関連付けられたオブジェクト識別子は、アークid-pkix内のアークid-peの下で定義されます。インターネットPKI用に将来定義される拡張も、アークid-peの下で定義されることが期待されます。

code:pkix

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. 認証局情報アクセス

認証局情報アクセス拡張は、この拡張が含まれる証明書の発行者の情報およびサービスへのアクセス方法を示します。情報およびサービスには、オンライン検証サービスやCAポリシーデータが含まれる場合があります。（CRLの場所はこの拡張では指定されません。その情報はcRLDistributionPoints拡張によって提供されます。）この拡張は、エンドエンティティ証明書またはCA証明書に含めることができます。準拠CAは、この拡張を非クリティカルとしてマークする必要があります。

code:authorityInfoAccess

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 シー​​ケンス内の各エントリは、この拡張機能が含まれる証明書の発行者が提供する追加情報の形式と場所を記述します。情報の種類と形式は accessMethod フィールドで指定され、accessLocation フィールドは情報の場所を指定します。取得メカニズムは accessMethod によって暗示されるか、accessLocation によって指定されます。

このプロファイルでは、2 つの accessMethod OID（id-ad-caIssuers と id-ad-ocsp）を定義します。

公開鍵証明書において、id-ad-caIssuers OID は、追加情報にこの拡張機能を含む証明書を発行した CA に発行された証明書がリストされている場合に使用されます。参照される CA 発行者記述は、証明書ユーザーが信頼するポイントで終了する認証パスを選択する際に役立ちます。

id-ad-caIssuers が accessMethod として指定されている場合、accessLocation フィールドは、参照される記述サーバと、参照される記述を取得するためのアクセスプロトコルを記述します。 accessLocation フィールドは GeneralName として定義され、複数の形式を取ることができます。

証明書へのアクセスにHTTPまたはFTPをサポートする準拠アプリケーションは、個々のDERエンコードされた証明書を受け入れることができなければならず（MUST）、また、「certs-only」CMSメッセージを受け入れることができるべきです（SHOULD）。

その他の id-ad-caIssuers accessLocation 名形式のセマンティクスは定義されていません。

追加のアクセス記述子は、他の PKIX 仕様で定義される場合があります。

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

サブジェクト情報アクセス拡張は、この拡張が含まれる証明書のサブジェクトの情報およびサービスへのアクセス方法を示します。サブジェクトが認証局（CA）の場合、情報およびサービスには証明書検証サービスや認証局（CA）ポリシーデータが含まれる場合があります。サブジェクトがエンドエンティティ（EEntity）の場合、この情報は提供されるサービスの種類とそれらへのアクセス方法を記述します。この場合、この拡張の内容は、サポートされるサービスのプロトコル仕様で定義されます。この拡張は、エンドエンティティ証明書またはCA証明書に含めることができます。準拠認証局（CA）は、この拡張を非クリティカルとしてマークする必要があります。

code:subjectInfoAccess

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

SubjectInfoAccessSyntax ::=

SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription ::= SEQUENCE {

accessMethod OBJECT IDENTIFIER,

accessLocation GeneralName }

SubjectInfoAccessSyntax シー​​ケンス内の各エントリは、この拡張機能が含まれる証明書のサブジェクトが提供する追加情報の形式と場所を記述します。情報の種類と形式は accessMethod フィールドで指定され、accessLocation フィールドは情報の場所を指定します。取得メカニズムは accessMethod によって暗黙的に示されるか、accessLocation によって指定されます。

このプロファイルは、サブジェクトが CA の場合に使用するアクセス方法を 1 つと、サブジェクトがエンドエンティティの場合に使用するアクセス方法を 1 つ定義します。将来、他のサービスのプロトコル仕様において、追加のアクセス方法が定義される可能性があります。

id-ad-caRepository OID は、サブジェクトが CA であり、発行した証明書をリポジトリで公開する場合に使用されます。accessLocation フィールドは GeneralName として定義され、複数の形式を取ることができます。

<host> を省略すると（例：<ldap:///cn=exampleCA,dc=example,dc=com?cACertificate;binary>）、クライアントが適切なサーバーに接続する際に、事前にどのような情報を持っているかに依拠することになります。

証明書へのアクセスに HTTP または FTP をサポートする準拠アプリケーションは、個々の DER エンコードされた証明書を受け入れることができなければならず（MUST）、また、「certs-only」CMS メッセージを受け入れることができるべきです（SHOULD）。

その他のid-ad-caRepository accessLocation名形式のセマンティクスは定義されていません。

追加のアクセス記述子は、他の PKIX 仕様で定義される場合があります。

code:ad

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

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

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