S/MIME 証明書のプロファイル

この記事では、S/MIME でメールの署名と暗号化を行う場合に使用する X.509 チェーンの各証明書が信頼を得るために必要な要件について説明します。

こうした要件を満たすことに加え、S/MIME でメールの署名と暗号化を行うことを Google によって明示的に認定された認証局（CA）証明書を、チェーンに組み込む必要があります。管理者が認定する CA のルート証明書の使用を許可することもできます。詳しくは、ルート証明書のガイドラインに関する記事をご覧ください。

注:

• Google は、Gmail for S/MIME による信頼を得ている CA 証明書の一覧を提供、管理しています。この一覧にある CA は Google 独自の裁量で信頼できると判断したものであり、Google はいつでも予告なくルート CA を削除する権利を保持しています。
• 証明書に組み込まれた拡張情報が、同じ証明書内の他の拡張情報と矛盾していないことを確認してください。たとえば nsCertType が定義されている場合、そうした定義は鍵の用途の拡張情報、鍵の拡張的用途の拡張情報、および基本制約の拡張情報とまったく同じ使用目的を規定している必要があります。

証明書チェーンのルール

ルート CA

フィールド	値
発行者識別名	CA を識別できる値にする必要があります。 たとえば、「認証局」のような一般的な値を使用することはできません。
主体者識別名	エンコード形式は、発行者識別名とバイト単位で同じでなければなりません。
主体者公開鍵情報	RSA モジュラス（2048、3072、または 4096）による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey。

発行元の中間 CA 以外の中間 CA の証明書

ルートとエンド エンティティの間に直接的または間接的に複数の中間 CA が存在する場合、この情報を使用します。

発行元の中間 CA が、エンド エンティティ証明書を発行する中間 CA です。以下の情報は、チェーン内の発行元の中間 CA 以外の中間 CA に該当します。

フィールド			値
バージョン			バージョン 3
シリアル番号			ゼロ（0）より大きく、（INTEGER 型を使用した DER エンコードの場合は）20 バイト以下でなければなりません。
署名アルゴリズム			SHA‐256、SHA‐384、SHA‐512 のいずれかを使った RSA。または、SHA‐256、SHA‐384、SHA‐512 のいずれかを使った ECDSA。
発行者識別名			発行元 CA の主体者識別名とバイト単位で同じでなければなりません。
有効期間			規定はありません。
主体者識別名			規定はありません。
主体者公開鍵情報			RSA モジュラス（2048、3072、または 4096）による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey。
拡張情報	必須かどうか	クリティカルかどうか	値
鍵の用途	必須	クリティカル	keyCertSign のビット位置を設定する必要があります。 他のビット位置を設定する可能性があります。
基本制約	必須	クリティカル	cA フィールドを TRUE に設定する必要があります。 pathLenConstraint フィールドを含めます。
CRL 配布ポイント	必須	クリティカルでない	一般公開されている 1 つ以上の HTTP uniformResourceIdentifier が存在する必要があります。
（注）			失効サーバーは、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、次のセクションに沿って運用する必要があります。 4.9.7. CRL 発行間隔 4.9.9. オンライン失効、ステータス チェックの可用性 4.9.10. オンライン失効チェックの要件 4.10.2 サービスの可用性
その他の拡張情報			存在する可能性があります。

エンド エンティティ証明書を発行する中間 CA 証明書

重要: 少なくとも 1 つの中間 CA 証明書がチェーン内に存在する必要があります。つまり、ルート CA がエンド エンティティ証明書を直接発行することは許可されていません。

フィールド			値
バージョン			バージョン 3
シリアル番号			ゼロ（0）より大きく、（INTEGER 型を使用した DER エンコードの場合は）20 バイト以下でなければなりません。
署名アルゴリズム			SHA‐256、SHA‐384、SHA‐512 のいずれかを使った RSA。または、SHA‐256、SHA‐384、SHA‐512 のいずれかを使った ECDSA。
発行者識別名			発行元 CA の主体者識別名とバイト単位で同じでなければなりません。
有効期間			notBefore と notAfter の間隔は 10 年以内であることが望ましく、20 年以内でなければなりません。
主体者識別名			CA の使用を示します。
主体者公開鍵情報			RSA モジュラス（2048、3072、または 4096）による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey。
拡張情報	必須かどうか	クリティカルかどうか	値
鍵の用途	必須	クリティカル	次のビット位置を設定する必要があります。     keyCertSign 次のビット位置を設定する可能性があります。     cRLSign     digitalSignature OCSP レスポンスの署名に直接使用する場合は、次の情報が存在している必要があります。     digitalSignature 他のビット位置を設定してはなりません。
鍵の拡張的用途	必須	任意	次の情報が存在しなければなりません。     emailProtection 次の情報が存在してはなりません。     serverAuth     codeSigning     timeStamping ​    anyExtendedKeyUsage
基本制約	必須	クリティカル	cA フィールドを TRUE に設定する必要があります。 pathLenConstraint フィールドを 0 にします。
証明書ポリシー	省略可能	クリティカルでない	CA の運用基盤であるポリシーを識別する policyIdentifier を指定します。anyPolicy は望ましくありません。 cps（存在する場合）には、有効な HTTP または HTTPS のリンクを含める必要があります。
CRL 配布ポイント	必須	クリティカルでない	一般公開されている 1 つ以上の HTTP uniformResourceIdentifier が存在する必要があります。
（注）			失効サーバーは、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、次のセクションに沿って運用する必要があります。   4.9.7. CRL 発行間隔   4.9.9. オンライン失効、ステータス チェックの可用性   4.9.10. オンライン失効チェックの要件   4.10.2. サービスの可用性
その他の拡張情報	省略可能	クリティカルでない	存在する可能性があります。

エンド エンティティ証明書

フィールド			値
バージョン			バージョン 3
シリアル番号			ゼロ（0）より大きく、予測不可能な 64 ビット以上を指定する必要があります。 注: CA/Browser Forum の「証明書ポリシーに関する基本要件」エンド エンティティ シリアル番号エントロピー要件を反映するように更新されます。
署名アルゴリズム			SHA‐256、SHA‐384、SHA‐512 のいずれかを使った RSA。または、SHA‐256、SHA‐384、SHA‐512 のいずれかを使った ECDSA。
発行者識別名			発行元 CA の主体者識別名とバイト単位で同じでなければなりません。
有効期間			notBefore と notAfter の間隔は 27 か月以内でなくてはなりません。 notBefore の時刻は署名時刻の前後 48 時間以内でなければなりません。
主体者識別名			メールアドレス以外の主体者関連識別名は、一般公開され監査済みの手順に沿って、発行前に厳格な検証を受ける必要があります。使用できる手順については、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、セクション 3.2.3「個人の認証」をご覧ください。 また、任意のメールアドレス（commonName フィールド内や emailAddress フィールド内など）が、主体者代替名拡張情報に rfc822Name 形式で存在する必要があります。
主体者公開鍵情報			RSA モジュラス（2048、3072、または 4096）による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey。
拡張情報	必須かどうか	クリティカルかどうか	値
鍵の用途（RSA）	必須	クリティカル	次のいずれかまたは両方のビット位置を設定する必要があります。     digitalSignature  または     nonRepudiation/contentCommitment 次のビット位置を設定する可能性があります。     dataEncipherment     keyEncipherment 他のビット位置を設定してはなりません。
鍵の用途（ECDH）	必須		次のビット位置を設定する必要があります。     digitalSignature 次のビット位置を設定する可能性があります。     nonRepudiation/contentCommitment     keyAgreement     encipherOnly（keyAgreement を設定する場合）     decipherOnly（keyAgreement を設定する場合） 他のビット位置を設定してはなりません。
鍵の拡張的用途	必須	任意	次の情報が存在しなければなりません。    emailProtection 次の情報が存在してはなりません。    serverAuth    codeSigning    timeStamping    anyExtendedKeyUsage
基本制約	省略可能	任意	存在する場合、cA フィールドを TRUE に設定してはなりません。 pathLenConstraint フィールドが存在してはなりません。
証明書ポリシー	必須	クリティカルでない	policyIdentifier が存在しなければなりません。これは、証明書発行の基盤であるポリシーを識別するものです。また、anyPolicy を指定してはなりません。 cps が存在する可能性があります。存在する場合には、証明書発行の基盤である CPS への有効な HTTP または HTTPS リンクを含める必要があります。
認証局情報アクセス	省略可能	クリティカルでない	caIssuers と ocsp（存在する場合）には、一般公開されている 1 つ以上の HTTP uniformResourceIdentifier を含める必要があります。 AccessDescription には、個人の証明書に固有のラベルやパラメータを含めてはなりません。
CRL 配布ポイント	必須	クリティカルでない	一般公開されている 1 つ以上の HTTPuniformResourceIdentifier が存在する必要があります。
（注）			失効サーバーは、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、次のセクションに沿って運用する必要があります。    4.9.7. CRL 発行間隔    4.9.9. オンライン失効、ステータス チェックの可用性    4.9.10. オンライン失効チェックの要件    4.10.2. サービスの可用性
主体者代替名	必須	クリティカルでない	rfc822Name 形式の項目を 1 つ以上含める必要があります。 次の形式の項目を含めてはなりません。    dNSName    iPAddress    uniformResourceIdentifier それぞれの rfc822Name は、リクエストを送信するエンティティが、メールアドレスに関連付けられたメール アカウントを制御している、またはそのメール アカウント所有者から代理で行動する許可を得ていることを確認するために、一般公開され監査済みの手段で検証する必要があります。
その他の拡張情報	省略可能	クリティカルでない	存在する可能性があります。